Patent Description:
Although Redis is an open-source database, often enterprises ("Service Consumers") may prefer to use a managed version of Redis provided by Platform as a Service (PaaS) vendors ("PaaS vendors") such as AMAZON® Web Services ("AWS"), or MICROSOFT® Azure. The PaaS vendors manage the provisioning (configuration, deployment and management of IT system resources) patching and other operations of the Redis instances while providing the Service Consumers with ease of simply accessing the Redis instance via a convenient network endpoint. PaaS vendors may offer services that may not be suitable to the Service Consumer workloads.

It would therefore be desirable to provide the functionality of Redis in a manner that is more tailored to the Service Consumer workloads.

In the following detailed description, numerous specific details are set forth in order to provide a thorough understanding of embodiments. However, it will be understood by those of ordinary skill in the art 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.

It should be appreciated 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 compliance with system-related and business-related constraints, which may vary from one implementation to another.

One or more embodiments or elements thereof can be implemented in the form of a computer program product including a non-transitory computer readable storage medium with computer usable program code for performing the method steps indicated herein. Furthermore, one or more embodiments or elements thereof can be implemented in the form of a system (or apparatus) including a memory, and at least one processor that is coupled to the memory and operative to perform exemplary method steps. Yet further, in another aspect, one or more embodiments or elements thereof can be implemented in the form of means for carrying out one or more of the method steps described herein; the means can include (i) hardware module(s), (ii) software module(s) 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) implement the specific techniques set forth herein.

Enterprises may use one or more applications as part of their computing infrastructure, and may also use an external organization for their data persistency requirements. In particular the enterprise may use a PaaS, which in turn may use Redis for data persistency. At least one of these applications may have a requirement to store their customer's source application/data in an isolated fashion. To that end, an enterprise may request a Redis instance for each customer. For example, the enterprise may store Customer A's data on Redis instance ("instance") A and Customer B's data on instance B. A first problem with the provisioning of an instance of each customer is that it takes about <NUM> minutes to provision or de-provision an instance. As such, if the frequency of customer provisioning/de-provisioning is high, this process may take a lot of time. As used herein, the output of a provisioning process is that the endpoint coordinates for the instance are delivered to the requestor in a matter of seconds, or other short amount of time. Once provisioned, all requests for data are read/write requests to the instance using the endpoint coordinates. As used herein, the terms "provisioning" and "onboarding" maybe used interchangeably; and the terms "deprovisioning" and "offboarding" may be used interchangeably. It is however noted that that the terms onboarding/offboarding are more often used in the context of a customer and provisioning/deprovisioning are more used in the context of a Redis instance (e.g., when Customer A onboards we provision a logical Redis instance for that customer). A second problem with the provisioning of an instance for each customer is the cost of the actual instance. By dedicating one instance for each customer, as the customer base grows, the costs may spiral up.

Additionally, PaaS vendors typically offer various "tiers" or "plans" of a managed Redis service to Service Consumers with varying pricing according to the compute capabilities of the "tier" and other service level agreement factors, including but not limited to, high availability, disaster recovery (DR) capability, etc. The PaaS vendor may have a fixed set of these "tiers" predefined, which may or may not be suitable to the Service Consumer workload. As such, the Service Consumer may be forced to choose a service tier that is more than their application's needs. For example, there may be a Redis instance of 6GB, which may be too much for Customer A, a good amount for Customer B, and not enough for Customer C. It may be a challenge for enterprises that they cannot select an optimal instance size, as this may translate into paying more money than optimal for any given application's workload.

Embodiments provide a shared cluster platform (e.g., shared Redis cluster platform) to address these problems. In embodiments, the shared cluster platform provides a shared/multitenant version of Redis instances by leveraging features supported by a protocol aware proxy, while continuing to use the Redis service offered by the PaaS vendor, behind the scenes. The shared cluster platform provides for multiple tenants to share a single large data store instance, while maintaining isolation of customer/tenant data, via a unique key element assigned to each tenant and attached to all data requests for that tenant, as described further below. Embodiments provide benefits to a Service Consumer's application including, but not limited to, optimum usage of the data store instance by using a single large, shared data store instance across multiple tenants and an opportunity to implement a cost optimal solution. Embodiments may also provide for a physical data store instance to be pre-created for the enterprise prior to a request from an application, such that provisioning of a logical data store instances may take a matter of seconds, rather than minutes, allowing for the provision of logical data store instances "on the fly". As used herein, the logical data store instance is a proxy instance for the physical data store instance in that the requesting application will contact the logical data store instance instead of the physical data store instance for data operations. Additionally, in scenarios that the physical data store instance is not pre-created, other than the initial procurement of the physical data store instance, the provisioning of the logical data store instance to each tenant thereafter may take seconds, as opposed to minutes.

<FIG> is a high-level block diagram of system architecture according to some embodiments. Embodiments are not limited to architecture <NUM>.

Architecture <NUM> may include a one or more service consumer applications <NUM> and a shared cluster platform <NUM>. The service consumer application <NUM> may send a request to a shared cluster platform <NUM>. The service consumer applications <NUM> may comprise executable program code (e.g., compiled code, scripts, etc.) to receive queries from users <NUM> and provide results to the users <NUM> based on electronic record data <NUM> stored in a Redis instance <NUM> ("physical data store instance"). Architecture <NUM> also includes a Service Broker <NUM>, Metadata Storage <NUM>, an Orchestrator <NUM>, a Container Engine <NUM>, and a Redis provider <NUM>.

One or more service consumer applications <NUM> may communicate with the shared cluster platform <NUM> using Redis client libraries including, but not limited to, IORedis, Jedis. These types of applications may use the Application Programming Interface (API) provided by these Redis client libraries to manage and query data stored in the physical data store instance <NUM>.

The Redis provider <NUM> is a PaaS vendor and the entity responsible for providing Redis instances as a service. Non-exhaustive examples of a Redis provider <NUM> are AMAZON® Web Services ("AWS") and MICROSOFT® Azure.

The Service Broker <NUM> may be a software application that is responsible to accept requests on behalf of the service consumer application <NUM> to provision and deprovision data store instances. The Service Broker <NUM> may act as a "middleman" between the service consumer's application <NUM> and the Redis provider <NUM> which provides a physical data store instance <NUM>. The instance provisioned by the Service Broker <NUM> to the service consumer application <NUM> may be referred to herein as a logical data store instance <NUM>.

The Orchestrator <NUM> is a software application that is responsible to assess the currently provisioned physical data store instances <NUM> and determine if there is a need to provision more from the Redis provider <NUM>. The Orchestrator <NUM> may also store data related to the current consumption/occupancy level for a physical data store instance <NUM> as well as a threshold level <NUM> set by the service consumer application. The Orchestrator <NUM> may use this stored data to select a physical data store instance <NUM> on which a logical data store instance <NUM> is to be created, as described further below. The Orchestrator <NUM> may request additional physical data store instance from the Redis provider <NUM> or may deprovision/return physical data store instances to the Redis provider <NUM> as needed, based on the one or more pre-set threshold levels <NUM>.

The Metadata Storage <NUM> may be a logical storage accessible to the Orchestrator <NUM> and Service Broker <NUM>. The Metadata Storage <NUM> may hold the data used to execute the processes described herein.

The Container Engine <NUM> may be either an on-premise or in-cloud container orchestration engine that generates software containers <NUM>. A non-exhaustive example of a container engine is Docker®.

According to some embodiments, devices, including those associated with system architecture <NUM> and any other device described herein, may exchange information via any communication network which may be one or more of a Local Area Network ("LAN"), a Metropolitan Area Network ("MAN"), a Wide Area Network ("WAN"), a proprietary network, a Public Switched Telephone Network ("PSTN"), a Wireless Application Protocol ("WAP") network, a Bluetooth network, a wireless LAN network, and/or an Internet Protocol ("IP") network such as the Internet, an intranet, or an extranet. Note that any devices described herein may communicate via one or more such communication networks.

The elements of the system <NUM> may store information into and/or retrieve information from various data stores (e.g., the Metadata Storage <NUM>), which may be locally stored or reside remote from the shared cluster platform <NUM>. Although a single Shared Cluster Platform <NUM> is shown in <FIG>, any number of such devices may be included. Moreover, various devices described herein might be combined according to embodiments of the present invention. For example, in some embodiments, the service consumer applications <NUM> and Service Broker <NUM> might comprise a single apparatus. Some or all of the system <NUM> functions may be performed by a constellation of networked apparatuses, such as in a distributed processing or cloud-based architecture.

A user <NUM> (e.g., a database administrator) may access the system <NUM> via a remote device (e.g., a Personal Computer ("PC"), tablet, or smartphone) to view information about and/or manage operational information in accordance with any of the embodiments described herein. In some cases, an interactive graphical user interface display may let an operator or administrator define and/or adjust certain parameters (e.g., to setup threshold values) and/or provide or receive automatically generated results from the system <NUM>.

Embodiments may provide a large shared multi-tenant version of a Redis instance that maintains security of the different tenants sharing the instance. <FIG> and <FIG> illustrates a method to provision or deprovision a logical Redis instance, respectively, according to some embodiments. The flow charts described herein do not imply a fixed order to the steps, and embodiments of the present invention may be practiced in any order that is practicable. Note that any of the methods described herein may be performed by hardware, software, an automated script of commands, or any combination of these approaches. For example, a computer-readable storage medium may store thereon instructions that when executed by a machine result in performance according to any of the embodiments described herein. As another example, the Shared Cluster Platform <NUM> may be conditioned to perform the process <NUM>/<NUM>, such that a processor <NUM> (<FIG>) of the system <NUM> is a special purpose element configured to perform operations not performable by a general-purpose computer or device.

All processes mentioned herein may be executed by various hardware elements and/or embodied in processor-executable program code read from one or more of non-transitory computer-readable media, such as a hard drive, a floppy disk, a CD-ROM, a DVD-ROM, a Flash drive, Flash memory, a magnetic tape, and solid state Random Access Memory (RAM) or Read Only Memory (ROM) storage units, and then stored in a compressed, uncompiled and/or encrypted format. In some embodiments, hard-wired circuitry may be used in place of, or in combination with, program code for implementation of processes according to some embodiments. Embodiments are therefore not limited to any specific combination of hardware and software.

Prior to the process <NUM>, the Orchestrator <NUM> requests one or more physical data store instances <NUM> from the Redis provider <NUM>. The physical data store instance <NUM> may be assigned in response to the Orchestrator's request, with the Orchestrator <NUM> receiving an endpoint address <NUM> (host name/IP address) to access the physical data store instance <NUM>. The endpoint address <NUM> for one or more physical data store instances <NUM>, which together form a pool of the physical instances may be stored in a metadata storage ("pool") <NUM> of the Shared Cluster platform <NUM>. In some embodiments, these physical data store instances <NUM> may be created prior to a request by a service consumer's application ("application") <NUM>, while in other embodiments, a first physical data store instance <NUM> may be created when an application requests the instance. A number of created physical data store instances <NUM> in the pool <NUM> may be based on a particular application's <NUM> requirements. The Orchestrator <NUM> may store configuration rule data <NUM> indicating a maximum number of logical data store instances <NUM> that may be created on a given physical data store instance <NUM>. This maximum number may be referred to herein as "maxTenantsAllowed" <NUM>.

Initially, at S210, an application <NUM> sends a request <NUM> to the Service Broker <NUM> to provision a new instance for a tenant <NUM> (<FIG>) being on-boarded. The tenant <NUM> may be one physical customer or end-user of the consumer application. As used herein, "on-boarding" may refer to the process of adding a new tenant to the system such that they may access their stored data via the requesting application. It is noted that in some instances, the customer may not directly access the data but may invoke some function in the consuming application which in turn reads/writes data on behalf of the tenant to execute the requested function. After the on-boarding process is complete, the tenant will be able to access (read and write) to the instance.

Then in S212, a physical data store instance <NUM> is selected. Upon receiving the request, the Service Broker <NUM> sends a request to the Orchestrator <NUM> to select a physical data store instance <NUM> from the pool <NUM>. The Orchestrator <NUM> may select the physical data store instance <NUM> based on one or more configuration rules <NUM> stored at the Orchestrator <NUM> and data stored at the Metadata Storage <NUM> of the number of tenants using a given physical data store instance. The configuration rules <NUM> may be based on consumption, or consuming application specific configuration such as the aforementioned "maxTenantsAllowed. " In one or more embodiments, the configuration rules <NUM> may be set by an application <NUM> or any other suitable party. As a non-exhaustive example, the configuration rules <NUM> may have the Orchestrator <NUM> select a physical data store instance <NUM> which is consumed the most, i.e., the one where the current number of logical data store instances <NUM> is closest to the "maxTenantsAllowed" <NUM> to optimize the instance usage. The Orchestrator <NUM> applies this configuration rule <NUM> to the data stored at the Metadata Storage <NUM> to select the physical data store instance <NUM>. The data stored at the Metadata Storage indicates the current number of logical data store instances on the given physical data store instance. For example, if the rule is a maximum of ten tenants, and a given physical data store instance has ten tenants mapped thereto, the Orchestrator <NUM> will select another physical data store instance for the next tenant that makes a request.

After the Orchestrator <NUM> selects the physical data store instance <NUM>, the Orchestrator <NUM> transmits this selection to the Service Broker <NUM> in S214. The Service Broker <NUM> then creates a logical data store instance <NUM> on the physical data store instance <NUM> by requesting a corresponding container <NUM> from the container engine <NUM> for the tenant <NUM> in S216. The logical data store instance <NUM> is manifested as the container <NUM>. The container engine <NUM> generates the container <NUM> in S217. The inventors note that the container engine <NUM> may spawn a container in a matter of seconds, making the provisioning of a container much faster than the provisioning of a physical data store instance. As described above, the logical data store instance <NUM> is a proxy instance for the physical data store instance <NUM> in that the service consumer application <NUM> will contact the logical data store instance instead of the physical data store instance for data operations. The logical data store instance <NUM> may then execute the data operations by contacting the physical data store instance <NUM>. It is noted that the advantage of this additional "layer" of routing the request via the logical data store instance i.e., routing it via the container, is that the container provides the isolation part of the multi-tenancy. Each container has a unique password, unique key-prefix requirements for the request, which ensures tenant isolation. The container <NUM> may run an image of a protocol aware proxy server such as Envoy, Twemproxy, or any other suitable protocol aware proxy server/Redis-protocol aware proxy server. The image may identify the software processes that run in the software container. In the non-exhaustive example described herein, the image will identify the Envoy proxy. The protocol aware proxy container <NUM> may filter requests to the physical data store instance <NUM> by applying routing rules to ensure the tenant data is kept separate from other tenant data. The Service Broker <NUM> then stores a mapping of the logical data store instance <NUM>/container <NUM> to the tenant <NUM>.

Next the Service Broker <NUM> generates a unique key element <NUM> for the tenant <NUM> in S218. The unique key element <NUM> may be a string generated by any suitable random/unique string generator. As a non-exhaustive example, the Service Broker <NUM> may use a library function in any programming language to generate the string. The inventors note that it may be desirable for the unique key element to be randomly generated ("random string element") to enhance security and avoid others from easily guessing or inadvertently using the unique key element. The unique key element <NUM> may be used by the application <NUM> as a key prefix that is coupled to all data requests pertaining to a given tenant <NUM>. The unique key element <NUM> may be generated for a tenant in a <NUM>:<NUM> relationship.

The Service Broker <NUM> in S220 generates a second string to be used by application <NUM> as an authorization password <NUM> when accessing the container <NUM>. The authorization password <NUM> may also be a randomly generated string and may be generated in a same or different manner than the unique key element <NUM>. The Service Broker <NUM> may transmit the unique key element <NUM> and authorization password <NUM> to the application <NUM> and the Container Engine116. The application <NUM> may store a mapping between the tenant <NUM> and the generated unique key element <NUM> and the authorization password <NUM>.

In one or more embodiments, the container <NUM> may use an instance proxy filter configuration <NUM> that maps the tenant <NUM> to the selected physical data store instance <NUM> with the generated unique key element <NUM> and authorization password <NUM>. The instance proxy filter configuration <NUM> may also be configured with connection details of the selected physical data store instance <NUM>. A non-exhaustive example of the instance proxy filter configuration <NUM> is as follows:
prefix_routes:
case_insensitive:false
routes:
- prefix: "<generated_KeyPrefix>"
cluster: physical_redis_cluster
downstream_auth_password:
inline_string: "<generated_auth_password>".

The above configuration <NUM> instructs the proxy in the container to forward all data requests with the specified key prefix (unique key element) and to use the specified auth password to the specified physical redis cluster. Any request coming with an incorrect key prefix and/or auth password will be rejected. This effectively forces the application <NUM> to use the key prefix (unique key element <NUM>) and auth password <NUM> and blocks the access for any non-conforming request.

The use of the unique key element <NUM> and auth password <NUM> may make each tenant "feel" that they have their own dedicated instance, as each tenant has a different logical data store endpoint/container authorization password to access what is ultimately a shared physical data store instance. The use of the unique key element <NUM> and auth password <NUM> may prevent the data for different tenants from clashing and/or prevent tenants from accessing data that is not theirs. In other words, as the tenants are sharing a single physical data store instance <NUM>, assigning a unique key element <NUM> and auth password <NUM> for each tenant may keep the data isolated. For example, both Tenant A and Tenant B may use a key field "Name," and both tenants may want to enter values for the "Name" field (e.g., for Tenant A, "Name" = Bond; and for Tenant B "Name" = Smith). However, without the use of the unique key element and auth password, Tenant B's values may override Tenant A's values because they are using the same fields in the shared physical data store instance. This overriding may be referred to as "clashing of data". Embodiments assign the unique key element <NUM> to the tenant for the tenant to use on all data requests to keep the data for a given tenant isolated from the data for another tenant. The unique key element <NUM> may be used as a prefix on the data requests. Continuing with the above examples, Tenant A is assigned a unique key element <NUM> of ABC, (prefix: "generated_KeyPrefix" = ABC), and the cluster identifies the address to which the data is forwarded. All of Tenant A's operations may use this prefix - ABC. To that end, the key value for the Name key stored for Tenant A is ABC_Name = Bond. The container <NUM> may enforce the key value <NUM> as the container <NUM> knows the address of the party making the request, and in a case a tenant does not use the assigned unique key element <NUM> in the data operation, the operation is rejected.

Turning back to the process <NUM>, in S222 the Service Broker <NUM> transmits a container connection endpoint <NUM> (i.e., hostname/IP address) of the container <NUM> to the application <NUM> as an endpoint of the logical data storage instance <NUM> for that given tenant <NUM>. The container connection endpoint <NUM> is a proxy for the endpoint of the selected physical data store instance. It is noted in one or more embodiments, the application <NUM> does not know the coordinates (hostname/IP address) of the physical data store instance <NUM>, just the container connection endpoint <NUM>. It is noted that the application <NUM> also does not know the password of the physical data store instance; and that instead the application <NUM> is aware of the container's coordinates and password. The transmission of the container connection endpoint <NUM> may fulfill the onboard request <NUM>. The application <NUM> then stores a mapping between the tenant <NUM> (including the assigned key element <NUM> and authorization password <NUM>) and the generated container connection endpoint <NUM> in S224. Because the container <NUM> running the image of the proxy server is aware of the physical data store instance <NUM> protocol, the application <NUM> may continue to use any standard data store instance client library, while connecting to this container <NUM> running the image of the proxy server.

In one or more embodiments, the Service Broker <NUM> may also store the mapping between the provisioned logical data store instance <NUM>, the physical data store instance <NUM> it is mapped to and information about the container connection endpoint spawned for this logical data store instance <NUM>, as shown in the table <NUM> in <FIG>.

This process <NUM> may be repeated to provision additional containers <NUM> to tenants <NUM>, where the additional containers <NUM> are mapped to a same physical data store instance <NUM>, or a different physical data store instance, based on the configuration rules <NUM>.

In one or more embodiments, while process <NUM> is executing, the Orchestrator <NUM> may, in the background, monitor the mappings of tenants <NUM> to the physical data store instances <NUM> (i.e., monitor when logical data store instances are created to assess the consumption/occupancy levels of the physical data store instances in the pool). In a case the Orchestrator <NUM> determines that the occupancy level of the physical data store instances is greater than a pre-set threshold value <NUM>, then the Orchestrator <NUM> may provision additional physical data store instances <NUM> from the Redis provider <NUM> or deprovision physical data store instances <NUM> back to the Redis provider <NUM>, and update the Metadata Storage <NUM> accordingly. This monitoring may ensure a pool of physical data store instances is maintained at optimum levels to serve future needs. As a non-exhaustive example, if the threshold value <NUM> is <NUM>%, such that when a number of logical data store instances is greater or equal to <NUM>% of the maxTenantsAllowed <NUM>, the Orchestrator <NUM> will provision another physical data store instance.

Turning to <FIG>, a method <NUM> to deprovision the logical data store instance is provided.

Initially, at S310, the application <NUM> detects that a tenant <NUM> has offboarded. This detection may vary from application to application. As a non-exhaustive example, the offboarding may be detection by the application in a case the customer/end-user unsubscribes from the application and/or deletes their account. Then, at S312, the application <NUM> transmits a request <NUM> to the Service Broker <NUM> to deprovision a logical data store instance <NUM>. In response to receiving the request, the Service Broker <NUM> deletes the container <NUM> corresponding to the logical data store instance being deleted in S314. This deletion effectively cuts-off the application <NUM> from the backing physical data store instance <NUM>. Next, in S316, the metadata storage <NUM> is updated to reflect this deletion.

As with process <NUM>, while process <NUM> is executing, the Orchestrator may, in the background, monitor the mappings of tenants to the physical data store instances <NUM> and may decide to delete/deprovision one or more physical data store instances to ensure that the pool of physical data store instances is maintained at optimum level to serve future needs.

Turning to <FIG> and <FIG>, a method <NUM> of how the application <NUM> accesses the physical data store instance <NUM> is provided.

Initially, at S410 the application <NUM> receives a request <NUM> for a data operation (i.e., a read/write/delete/update operation). The application <NUM> identifies the request as belonging to a given tenant 504a in S412. This identification may vary from application to application. As a non-exhaustive example, the identification may be based on information in the session, such as who is logged-in to the session. As shown in <FIG>, multiple tenants (504a, 504b and 504n) may each be mapped to a respective container 138a, 138b and 138n, and all of these containers 138a, 138b, 138c are all mapped to a same physical data store instance <NUM>. Then in S414, the application <NUM> obtains the container <NUM> connection details (connection endpoint, authorization password, unique key element) corresponding to this tenant, which it has previously obtained and stored as a table <NUM> in <FIG>.

Next, in S416, the application <NUM> provides the auth password <NUM> and unique key element <NUM> to the container <NUM>. It is noted that while both the auth password <NUM> and unique key element <NUM> are described in the S416 as being provided at a same, or substantially same, time, in other embodiments, they may be provided sequentially, with the auth password being provided first, and if approved, the key element is then provided. It is determined in S418, by the container <NUM>, whether the auth password <NUM> received from the consuming application matches the auth password stored for the tenant in the table <NUM> (<FIG>).

In a case the container <NUM> determined at S418 the auth password <NUM> received from the application <NUM> does not match the stored auth password <NUM>, the request for the data operation is denied and the process <NUM> ends at S420.

In a case the container <NUM> determines at S418 the auth password <NUM> received from the application <NUM> does match the stored auth password <NUM>, the process <NUM> continues to S422 and the container <NUM> determines whether the received unique key element <NUM> matches the stored unique key element <NUM> for that tenant.

In a case the container <NUM> determines at S422 the received unique key element <NUM> does not match the stored unique key element <NUM> for that tenant, the request for the data operation is denied, the process returns to S420 and ends.

In a case the container determines at S422 the received unique key element <NUM> does match the stored unique key element <NUM> for that tenant, in S424 the container <NUM> forwards the data operation request to the physical data store instance <NUM>. The physical data store instance <NUM> then executes the data operation in S426. In the case of a write operation, execution of the data operation results in the received data being written to the physical data store instance. In the case of a read operation, execution of the data operation results in data being retrieved from the physical data store instance and returned to the application <NUM> via the container <NUM> and Service Broker <NUM>.

As described herein, embodiments provide for multiple tenants to share a same large physical data store. The physical data store instance, however, may not restrict the tenants to certain amounts of storage. For example, if the physical data store instance is 6GB, the Orchestrator may set a configuration rule such that there can be a maximum of <NUM> tenants on each instance, with the idea that each tenant would have roughly 1GB of storage. The Shared Cluster Platform <NUM> cannot enforce this use of space between tenants as the physical data store instance does not monitor such information. As such, Tenant A may use more storage than its allocated 1GB. To address this, one or more embodiments may include an expiration/eviction policy <NUM> as stored by the Orchestrator <NUM> as part of the configuration rules <NUM>. The expiration/eviction policy <NUM> may be set such that after a given amount of time old data may be replaced by new data. The expiration/eviction policy <NUM> may also evict keys using a policy such as LRU (least recently used). For example, the expiration/eviction policy <NUM> may be set such that when a physical data store instance is full, the next write operation coming to the instance may result in the eviction of a key that is not frequently used. The incoming write operation may then use the space made available by the deleted/evicted key. The expiration/eviction policy <NUM> may ensure that no tenant experiences an "out of memory" error and seemingly gets unlimited memory. It is noted that even though the evicted data may not be available from the physical data store instance, the evicted data may be persisted in a more permanent data store. While embodiments may provide the expiration/eviction policy, the level of tenant isolation provided by embodiments may be more suited for development and testing scenarios than productive ones as a tenant may be less willing to share the singe large instance with other tenants in a production environment due to hard data store requirements (i.e., the tenant requires a set amount of storage), as described further below. However, the level of tenant isolation provided by embodiments may also be suited to productive environments.

Note that the embodiments described herein may be implemented using any number of different hardware configurations. For example, <FIG> is a block diagram of an apparatus or platform <NUM> that may be, for example, associated with the system100 of <FIG> (and/or any other system described herein). The platform <NUM> comprises a processor <NUM>, such as one or more commercially available CPUs in the form of one-chip microprocessors, coupled to a communication device <NUM> configured to communicate via a communication network (not shown in <FIG>). The communication device <NUM> may be used to communicate, for example, with one or more remote user platforms, tenant data sources, etc. The platform <NUM> further includes an input device <NUM> (e.g., a computer mouse and/or keyboard to input information about optimization preferences) and an output device <NUM> (e.g., a computer monitor to render a display, transmit data etc.). According to some embodiments, a mobile device and/or PC may be used to exchange information with the platform <NUM>.

The processor <NUM> also communicates with a storage device <NUM>. The storage device <NUM> can be implemented as a single database or the different components of the storage device <NUM> can be distributed using multiple databases (that is, different deployment information storage options are possible). The storage device <NUM> may comprise any appropriate information storage device, including combinations of magnetic storage devices (e.g., a hard disk drive), optical storage devices, mobile telephones, and/or semiconductor memory devices. The storage device <NUM> stores a program <NUM> and/or shared cluster engine <NUM> for controlling the processor <NUM>. The processor <NUM> performs instructions of the programs <NUM>, <NUM>, and thereby operates in accordance with any of the embodiments described herein. For example, the processor <NUM> may facilitate automated provisioning a given physical data store instance to multiple tenants.

The programs <NUM>, <NUM> may be stored in a compressed, uncompiled and/or encrypted format. The programs <NUM>, <NUM> may furthermore include other program elements, such as an operating system, clipboard application, a database management system, and/or device drivers used by the processor <NUM> to interface with peripheral devices.

As used herein, information may be "received" by or "transmitted" to, for example: (i) the platform <NUM> from another device; or (ii) a software application or module within the platform <NUM> from another software application, module, or any other source.

In some embodiments (such as the one shown in <FIG>), the storage device <NUM> further stores an application table data store <NUM> (<FIG>) and a container map data store <NUM> (<FIG>). An example of a database that may be used in connection with the platform <NUM> will now be described in detail with respect to <FIG>. Note that the databases described herein are only two examples, and additional and/or different information may be stored therein. Moreover, various databases might be split or combined in accordance with any of the embodiments described herein.

Referring to <FIG>, a table is shown that represents the application connection detail table <NUM> that may be stored at the platform <NUM> according to some embodiments. The table may include, for example, entries identifying tenants provisioned to a physical data store instance. The table may also define fields <NUM>, <NUM>, <NUM>, <NUM>, <NUM> for each of the entries. The fields <NUM>, <NUM>, <NUM>, <NUM>, <NUM> may, according to some embodiments, specify: a logical data store instance <NUM>, a container endpoint <NUM>, a key element identifier <NUM>, an authorization password identifier <NUM>, and a physical data store instance <NUM>. The application connection table data store <NUM> may be created and updated, for example, when a new tenant is provisioned/deprovisioned etc..

The key element <NUM> and authorization password <NUM> might be a unique alphanumeric label or link that is associated with a particular "tenant" in a multi-tenant shared cluster computing architecture that lets tenants share a same physical Redis instance. Each tenant's data may be isolated and remain invisible to other tenants. The logical instance identifier <NUM> might represent the logical instance created for that tenant. The container endpoint <NUM> may represent the endpoint coordinates for the container assigned to the tenant. The physical data store instance <NUM> may represent the physical data store instance shared by the tenant.

Referring to <FIG>, a table is shown that represents the container tenant table <NUM> that may be stored at the platform <NUM> according to some embodiments. The table may include, for example, entries identifying tenants provisioned to a physical data store instance. The table may also define fields <NUM>, <NUM>, and physical data store instance <NUM> for each of the entries. The fields <NUM>, <NUM> and <NUM> may, according to some embodiments, specify: a key element identifier <NUM>, an authorization password identifier <NUM> and a physical data store instance <NUM>. The container tenant table data store <NUM> may be created and updated, for example, when a new tenant is provisioned/deprovisioned etc..

The key element <NUM> and authorization password <NUM> might be a unique alphanumeric label or link that is associated with a particular "tenant" in a multi-tenant shared cluster computing architecture that lets tenants share a same physical Redis instance. Each tenant's data may be isolated and remain invisible to other tenants. The physical data store instance <NUM> may represent the physical data store instance shared by the tenant.

In this way, embodiments may facilitate the ability to use a physical Redis instance provided by PaaS vendors in a shared/multi-tenant fashion in an efficient and accurate manner. Embodiments may provide for the optimum usage of the PaaS vendor provided Redis service both capacity wise and cost wise by mapping each tenant to a logical Redis instance, rather than a physical Redis instance.

Embodiments may also improve the provision time of the data store instances, as well as provide a satisfactory level of "tenant isolation". Moreover, an increase of productivity, efficiency, and quality may be provided by the various embodiments described herein.

The following illustrates various additional embodiments of the invention. These do not constitute a definition of all possible embodiments, and those skilled in the art will understand that the present invention is applicable to many other embodiments. Further, although the following embodiments are briefly described for clarity, those skilled in the art will understand how to make any changes, if necessary, to the above-described apparatus and methods to accommodate these and other embodiments and applications.

Although specific hardware and data configurations have been described herein, note that any number of other configurations may be provided in accordance with some embodiments of the present invention (e.g., some of the information associated with the databases described herein may be combined or stored in external systems).

Claim 1:
A system (<NUM>) associated with a multi-tenant data store, comprising:
at least one physical data store instance (<NUM>, <NUM>, <NUM>) adapted to contain electronic records; and
a shared cluster platform (<NUM>), coupled to the data store, including:
a computer processor (<NUM>), and
a computer memory, coupled to the computer processor (<NUM>), storing instructions that, when executed by the computer processor cause the shared cluster platform to:
receive a request (<NUM>) for a first tenant (<NUM>, 504a, 504b, 504N);
select a physical data store instance (<NUM>, <NUM>, <NUM>) in response to the request (<NUM>);
generate a first container (<NUM>, 138a, 138b, 138N) for the first tenant (<NUM>, 504a, 504b, 504N), wherein the first container (<NUM>, 138a, 138b, 138N) maps the first tenant (<NUM>, 504a, 504b, 504N) to the selected physical data store instance (<NUM>, <NUM>, <NUM>) and manifests as a logical data store instance (<NUM>, <NUM>),
wherein the logical data store instance (<NUM>, <NUM>) is a proxy instance for the physical data store instance (<NUM>, <NUM>, <NUM>) in that the service consumer application (<NUM>) will contact the logical data store instance (<NUM>, <NUM>) instead of the physical data store instance (<NUM>, <NUM>, <NUM>) for data operations;
generate a unique first key element (<NUM>) for the first tenant (<NUM>, 504a, 504b, 504N); and
transmit a first endpoint (<NUM>, <NUM>) of the first container (<NUM>, 138a, 138b, 138N) as a proxy for the selected physical data store instance (<NUM>, <NUM>, <NUM>), wherein the transmission fulfills the request (<NUM>).