Method to implement multi-tenant/shared Redis cluster using envoy

A system and method are disclosed associated with at least one physical data store instance adapted to contain electronic records; and a shared cluster platform, coupled to the data store, including: a computer processor, and a computer memory, coupled to the computer processor, storing instructions that, when executed by the computer processor cause the shared cluster platform to: receive a request for a first tenant; select a physical data store 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 store instance; generate a unique first key element for the first tenant; and transmit a first endpoint of the first container as a proxy for the selected physical data store instance, wherein the transmission fulfills the request. Numerous other embodiments are provided.

BACKGROUND

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 may 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 may simplify code writing for an enterprise by enabling an enterprise developer to write fewer lines of code to store, access, and use data in the enterprise's applications. For example, if the 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 particular single installation of the Redis server with associated memory storage.

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.

DETAILED DESCRIPTION

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 20 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” may be 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 6 GB, 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.1is a high-level block diagram of system architecture according to some embodiments. Embodiments are not limited to architecture100.

Architecture100may include a one or more service consumer applications102and a shared cluster platform104. The service consumer application102may send a request to a shared cluster platform104. The service consumer applications102may comprise executable program code (e.g., compiled code, scripts, etc.) to receive queries from users105and provide results to the users105based on electronic record data106stored in a Redis instance108(“physical data store instance”). Architecture100also includes a Service Broker110, Metadata Storage112, an Orchestrator114, a Container Engine116, and a Redis provider118.

One or more service consumer applications102may communicate with the shared cluster platform104using 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 instance108.

The Redis provider118is a PaaS vendor and the entity responsible for providing Redis instances as a service. Non-exhaustive examples of a Redis provider118are AMAZON® Web Services (“AWS”) and MICROSOFT® Azure.

The Service Broker110may be a software application that is responsible to accept requests on behalf of the service consumer application102to provision and deprovision data store instances. The Service Broker110may act as a “middleman” between the service consumer's application102and the Redis provider118which provides a physical data store instance108. The instance provisioned by the Service Broker110to the service consumer application102may be referred to herein as a logical data store instance120.

The Orchestrator114is a software application that is responsible to assess the currently provisioned physical data store instances108and determine if there is a need to provision more from the Redis provider118. The Orchestrator114may also store data related to the current consumption/occupancy level for a physical data store instance108as well as a threshold level122set by the service consumer application. The Orchestrator114may use this stored data to select a physical data store instance108on which a logical data store instance120is to be created, as described further below. The Orchestrator114may request additional physical data store instance from the Redis provider118or may deprovision/return physical data store instances to the Redis provider118as needed, based on the one or more pre-set threshold levels122.

The Metadata Storage112may be a logical storage accessible to the Orchestrator114and Service Broker112. The Metadata Storage112may hold the data used to execute the processes described herein.

The Container Engine116may be either an on-premise or in-cloud container orchestration engine that generates software containers138. A non-exhaustive example of a container engine is Docker®.

The elements of the system100may store information into and/or retrieve information from various data stores (e.g., the Metadata Storage112), which may be locally stored or reside remote from the shared cluster platform104. Although a single Shared Cluster Platform104is shown inFIG.1, 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 applications102and Service Broker110might comprise a single apparatus. Some or all of the system100functions may be performed by a constellation of networked apparatuses, such as in a distributed processing or cloud-based architecture.

A user105(e.g., a database administrator) may access the system100via 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 system100.

Embodiments may provide a large shared multi-tenant version of a Redis instance that maintains security of the different tenants sharing the instance.FIGS.2and3illustrates 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 Platform104may be conditioned to perform the process200/300, such that a processor610(FIG.6) of the system100is 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 process200, the Orchestrator112requests one or more physical data store instances108from the Redis provider118. The physical data store instance108may be assigned in response to the Orchestrator's request, with the Orchestrator114receiving an endpoint address124(host name/IP address) to access the physical data store instance124. The endpoint address124for one or more physical data store instances108, which together form a pool of the physical instances may be stored in a metadata storage (“pool”)126of the Shared Cluster platform104. In some embodiments, these physical data store instances108may be created prior to a request by a service consumer's application (“application”)102, while in other embodiments, a first physical data store instance108may be created when an application requests the instance. A number of created physical data store instances108in the pool126may be based on a particular application's102requirements. The Orchestrator114may store configuration rule data128indicating a maximum number of logical data store instances120that may be created on a given physical data store instance108. This maximum number may be referred to herein as “maxTenantsAllowed”130.

Initially, at S210, an application102sends a request132to the Service Broker110to provision a new instance for a tenant504(FIG.5) being on-boarded. The tenant504may 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 instance124is selected. Upon receiving the request, the Service Broker110sends a request to the Orchestrator114to select a physical data store instance108from the pool126. The Orchestrator114may select the physical data store instance108based on one or more configuration rules128stored at the Orchestrator114and data stored at the Metadata Storage112of the number of tenants using a given physical data store instance. The configuration rules128may be based on consumption, or consuming application specific configuration such as the aforementioned “maxTenantsAllowed.” In one or more embodiments, the configuration rules128may be set by an application102or any other suitable party. As a non-exhaustive example, the configuration rules128may have the Orchestrator114select a physical data store instance108which is consumed the most, i.e., the one where the current number of logical data store instances120is closest to the “maxTenantsAllowed”130to optimize the instance usage. The Orchestrator114applies this configuration rule128to the data stored at the Metadata Storage112to select the physical data store instance108. 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 Orchestrator114will select another physical data store instance for the next tenant that makes a request.

After the Orchestrator114selects the physical data store instance108, the Orchestrator114transmits this selection to the Service Broker110in S214. The Service Broker114then creates a logical data store instance120on the physical data store instance108by requesting a corresponding container138from the container engine116for the tenant504in S216. The logical data store instance120is manifested as the container138. The container engine116generates the container138in S217. The inventors note that the container engine116may 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 instance120is a proxy instance for the physical data store instance108in that the service consumer application102will contact the logical data store instance instead of the physical data store instance for data operations. The logical data store instance120may then execute the data operations by contacting the physical data store instance108. 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 container138may 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 container138may filter requests to the physical data store instance108by applying routing rules to ensure the tenant data is kept separate from other tenant data. The Service Broker110then stores a mapping of the logical data store instance120/container138to the tenant504.

Next the Service Broker110generates a unique key element134for the tenant504in S218. The unique key element134may be a string generated by any suitable random/unique string generator. As a non-exhaustive example, the Service Broker110may 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 element134may be used by the application102as a key prefix that is coupled to all data requests pertaining to a given tenant504. The unique key element134may be generated for a tenant in a1:1relationship.

The Service Broker110in S220generates a second string to be used by application102as an authorization password136when accessing the container138. The authorization password136may also be a randomly generated string and may be generated in a same or different manner than the unique key element134. The Service Broker110may transmit the unique key element134and authorization password136to the application102and the Container Engine116. The application102may store a mapping between the tenant504and the generated unique key element134and the authorization password136.

In one or more embodiments, the container138may use an instance proxy filter configuration140that maps the tenant504to the selected physical data store instance108with the generated unique key element134and authorization password136. The instance proxy filter configuration140may also be configured with connection details of the selected physical data store instance108. A non-exhaustive example of the instance proxy filter configuration140is as follows:

The above configuration140instructs 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 application102to use the key prefix (unique key element134) and auth password136and blocks the access for any non-conforming request.

The use of the unique key element134and auth password136may 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 element134and auth password136may 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 instance108, assigning a unique key element134and auth password136for 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 element134to 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 element134may be used as a prefix on the data requests. Continuing with the above examples, Tenant A is assigned a unique key element134of 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 container138may enforce the key value134as the container138knows the address of the party making the request, and in a case a tenant does not use the assigned unique key element134in the data operation, the operation is rejected.

Turning back to the process200, in S222the Service Broker110transmits a container connection endpoint142(i.e., hostname/IP address) of the container138to the application102as an endpoint of the logical data storage instance120for that given tenant504. The container connection endpoint142is a proxy for the endpoint of the selected physical data store instance. It is noted in one or more embodiments, the application102does not know the coordinates (hostname/IP address) of the physical data store instance108, just the container connection endpoint142. It is noted that the application102also does not know the password of the physical data store instance; and that instead the application102is aware of the container's coordinates and password. The transmission of the container connection endpoint142may fulfill the onboard request132. The application102then stores a mapping between the tenant504(including the assigned key element134and authorization password136) and the generated container connection endpoint142in S224. Because the container138running the image of the proxy server is aware of the physical data store instance108protocol, the application102may continue to use any standard data store instance client library, while connecting to this container138running the image of the proxy server.

In one or more embodiments, the Service Broker110may also store the mapping between the provisioned logical data store instance120, the physical data store instance108it is mapped to and information about the container connection endpoint spawned for this logical data store instance120, as shown in the table700inFIG.7.

This process200may be repeated to provision additional containers138to tenants504, where the additional containers138are mapped to a same physical data store instance108, or a different physical data store instance, based on the configuration rules128.

In one or more embodiments, while process200is executing, the Orchestrator114may, in the background, monitor the mappings of tenants504to the physical data store instances108(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 Orchestrator114determines that the occupancy level of the physical data store instances is greater than a pre-set threshold value122, then the Orchestrator114may provision additional physical data store instances108from the Redis provider118or deprovision physical data store instances108back to the Redis provider118, and update the Metadata Storage112accordingly. 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 value122is 85%, such that when a number of logical data store instances is greater or equal to 85% of the maxTenantsAllowed130, the Orchestrator114will provision another physical data store instance.

Turning toFIG.3, a method300to deprovision the logical data store instance is provided.

Initially, at S310, the application102detects that a tenant504has 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 application102transmits a request132to the Service Broker110to deprovision a logical data store instance120. In response to receiving the request, the Service Broker110deletes the container138corresponding to the logical data store instance being deleted in S314. This deletion effectively cuts-off the application102from the backing physical data store instance108. Next, in S316, the metadata storage112is updated to reflect this deletion.

As with process200, while process300is executing, the Orchestrator may, in the background, monitor the mappings of tenants to the physical data store instances108and 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 toFIGS.4and5, a method400of how the application102accesses the physical data store instance108is provided.

Initially, at S410the application102receives a request506for a data operation (i.e., a read/write/delete/update operation). The application102identifies the request as belonging to a given tenant504ain 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 inFIG.5, multiple tenants (504a,504band504n) may each be mapped to a respective container138a,138band138n, and all of these containers138a,138b,138care all mapped to a same physical data store instance108. Then in S414, the application102obtains the container138connection details (connection endpoint, authorization password, unique key element) corresponding to this tenant, which it has previously obtained and stored as a table700inFIG.7.

Next, in S416, the application102provides the auth password136and unique key element134to the container138. It is noted that while both the auth password136and unique key element134are described in the S416as 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 container138, whether the auth password136received from the consuming application matches the auth password stored for the tenant in the table800(FIG.8).

In a case the container138determined at S418the auth password136received from the application102does not match the stored auth password836, the request for the data operation is denied and the process400ends at S420.

In a case the container138determines at S418the auth password136received from the application102does match the stored auth password836, the process400continues to S422and the container138determines whether the received unique key element134matches the stored unique key element834for that tenant.

In a case the container138determines at S422the received unique key element134does not match the stored unique key element834for that tenant, the request for the data operation is denied, the process returns to S420and ends.

In a case the container determines at S422the received unique key element134does match the stored unique key element834for that tenant, in S424the container138forwards the data operation request to the physical data store instance108. The physical data store instance108then 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 application102via the container138and Service Broker110.

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 6 GB, the Orchestrator may set a configuration rule such that there can be a maximum of 6 tenants on each instance, with the idea that each tenant would have roughly 1 GB of storage. The Shared Cluster Platform104cannot 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 1 GB. To address this, one or more embodiments may include an expiration/eviction policy144as stored by the Orchestrator114as part of the configuration rules128. The expiration/eviction policy144may be set such that after a given amount of time old data may be replaced by new data. The expiration/eviction policy144may also evict keys using a policy such as LRU (least recently used). For example, the expiration/eviction policy144may 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 policy144may 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.6is a block diagram of an apparatus or platform600that may be, for example, associated with the system100ofFIG.1(and/or any other system described herein). The platform600comprises a processor610, such as one or more commercially available CPUs in the form of one-chip microprocessors, coupled to a communication device620configured to communicate via a communication network (not shown inFIG.6). The communication device620may be used to communicate, for example, with one or more remote user platforms, tenant data sources, etc. The platform600further includes an input device640(e.g., a computer mouse and/or keyboard to input information about optimization preferences) and an output device650(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 platform600.

The processor610also communicates with a storage device630. The storage device630can be implemented as a single database or the different components of the storage device630can be distributed using multiple databases (that is, different deployment information storage options are possible). The storage device630may 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 device630stores a program612and/or shared cluster engine614for controlling the processor610. The processor610performs instructions of the programs612,614, and thereby operates in accordance with any of the embodiments described herein. For example, the processor610may facilitate automated provisioning a given physical data store instance to multiple tenants.

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

As used herein, information may be “received” by or “transmitted” to, for example: (i) the platform600from another device; or (ii) a software application or module within the platform600from another software application, module, or any other source.

In some embodiments (such as the one shown inFIG.6), the storage device630further stores an application table data store700(FIG.7) and a container map data store800(FIG.8). An example of a database that may be used in connection with the platform600will now be described in detail with respect toFIGS.7and8. 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 toFIG.7, a table is shown that represents the application connection detail table700that may be stored at the platform600according to some embodiments. The table may include, for example, entries identifying tenants provisioned to a physical data store instance. The table may also define fields702,704,706,708,710for each of the entries. The fields702,704,706,708,710may, according to some embodiments, specify: a logical data store instance702, a container endpoint704, a key element identifier706, an authorization password identifier708, and a physical data store instance710. The application connection table data store700may be created and updated, for example, when a new tenant is provisioned/deprovisioned etc.

The key element706and authorization password708might 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 identifier702might represent the logical instance created for that tenant. The container endpoint704may represent the endpoint coordinates for the container assigned to the tenant. The physical data store instance710may represent the physical data store instance shared by the tenant.

Referring toFIG.8, a table is shown that represents the container tenant table700that may be stored at the platform600according to some embodiments. The table may include, for example, entries identifying tenants provisioned to a physical data store instance. The table may also define fields834,836, and physical data store instance808for each of the entries. The fields834,836and808may, according to some embodiments, specify: a key element identifier834, an authorization password identifier836and a physical data store instance808. The container tenant table data store800may be created and updated, for example, when a new tenant is provisioned/deprovisioned etc.

The key element834and authorization password836might 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 instance808may 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.

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).