Aggregated health check of a multi-tenant service container

A multi-tenant service container receives a container health check request and responsively identifies a list of expected tenants. The list of expected tenants may include all of the tenants hosted by the multi-tenant service container, all of the tenants hosted by the multi-tenant service container that are associated with a particular process or a list of tenants defined by the container health check request. The multi-tenant service container issues a tenant health status request to the tenants in the expected tenant list and responsively receives a tenant health status from the tenants. The received tenant health status is either a tenant healthy status or a tenant unhealthy status. The multi-tenant service container issues a container health status based on the tenant health statuses received from the tenants on the expected tenant list.

BACKGROUND

Various types of execution environments can be utilized to provide software services. For example, one type of execution environment is a multi-tenant service container. A multi-tenant service container can be configured to cohost a number of different tenants (e.g. services or applications). In some cases, all or a subset of the tenants cohosted by a multi-tenant service container execute within the same process.

A load balancer configured with a virtual Internet protocol address may operate as an intermediary between customers and one or more multi-tenant service containers. The load balancer may track the availability of one or more associated multi-tenant service containers to determine the availability of the services executing within the multi-tenant service containers. A multi-tenant service container may be considered unable to support customer requests for access to the services associated with a process if the multi-tenant service container that supports the requested process is unavailable or unhealthy, or if the tenants hosted by the multi-tenant service container that provide the services associated with the requested process are unavailable or unhealthy.

The disclosure made herein is presented with respect to these and other considerations.

DETAILED DESCRIPTION

The following detailed description is directed to technologies for performing an aggregated health check of a multi-tenant service container. In order to provide this functionality, a load balancer may operate as an intermediary between client devices and one or more multi-tenant service containers. The load balancer may track the health status of one or more multi-tenant service containers associated with the load balancer to determine the availability of the use case supported by the multi-tenant service containers. Utilizing the technologies described herein, a multi-tenant service container performs an aggregated health check in response to a container health check request received from the load balancer and issues a container health status to the load balancer. If the issued container health status is a container healthy status, the multi-tenant service container is available for production network traffic. If the issued container health status is a container unhealthy status, the multi-tenant service container is unavailable for production network traffic. The load balancer will not route customer requests for access to services associated with a process if the multi-tenant service container that supports the requested services is unhealthy.

According to one aspect presented herein, a computer-implemented method is disclosed for performing an aggregated health check of a multi-tenant service container. In particular, the multi-tenant service container receives a container health check request from a load balancer. The multi-tenant service container determines whether the multi-tenant service container is configured for production network traffic. If the multi-tenant service container is not configured for production network traffic, the multi-tenant service container issues a container unhealthy status to the load balancer. The multi-tenant service container performs a general container health check. If the multi-tenant service container fails the general container health check, the multi-tenant service container issues a container unhealthy status to the load balancer.

If the multi-tenant service container is configured for production network traffic and passes the general container health check, the multi-tenant service container identifies an expected tenant list. The expected tenant list may include all of the tenants hosted by the multi-tenant service container, all of the tenants hosted by the multi-tenant service container that are associated with a particular use case or a list of tenants defined by the container health check request. The multi-tenant service container checks tenant health metadata associated with each of the tenants in the expected tenant list. A tenant may fail the tenant health metadata check if the tenant has more than one live release. If any one of the tenants on the expected tenant list fails the tenant health metadata check, the multi-tenant service container issues a container unhealthy status to the load balancer.

If none of the tenants in the expected tenant list fail the tenant health metadata check, the multi-tenant service container issues a tenant health check request to each of the tenants in the expected tenant list and receives a tenant health status from each of the tenants. The received tenant health status is either a tenant healthy status or a tenant unhealthy status. A tenant is considered to be unhealthy if the tenant fails a tenant ping health check. The multi-tenant service container issues a container health status based on the tenant health statuses received from the tenants on the expected tenant list. The multi-tenant service container issues a container healthy status to the load balancer if all of the tenant health statuses received from all of the tenants in the expected tenant list are tenant healthy statuses. The multi-tenant service container issues a container unhealthy status if at least one of the tenant health statuses received from the expected tenant list is a tenant unhealthy status.

According to another aspect presented herein, a computer-implemented method is disclosed for performing an aggregated health check of a multi-tenant service container. In particular, the multi-tenant service container receives a container health check request from a load balancer. The multi-tenant service container identifies an expected tenant list. The expected tenant list may include all of the tenants hosted by the multi-tenant service container, all of the tenants hosted by the multi-tenant service container that are associated with a particular use case or a list of tenants defined by the container health check request.

The multi-tenant service container creates a container status request/response object in response to the container health check request. The multi-tenant service container creates a tenant specific decorating request/response object based on the container status request/response object for a tenant in the expected tenant list. The multi-tenant service container isolates the underlying container status request/response object from the tenant specific decorating request/response object by resetting the internal status of the underlying container status request/response object. The multi-tenant service container sends the tenant specific decorating request/response object to the tenant and receives a processed tenant specific decorating request/response object from the tenant. The received processed tenant specific decorating request/response object indicates the tenant health status of the associated tenant. The tenant health status consists of either a tenant healthy status or a tenant unhealthy status. The multi-tenant service container repeats the process described above for each of the tenants in the expected tenant list.

The multi-tenant service container processes the container status request/response object based on an aggregation of the plurality of processed tenant specific decorating request/response objects and generates a container health status based on the processed container status request/response object. The multi-tenant service container issues a container healthy status to the load balancer if all of the tenant health statuses received from all of the tenants on the expected tenant list are tenant healthy statuses. The multi-tenant service container issues a container unhealthy status if at least one of the tenant health statuses received from the tenants on the expected tenant list is a tenant unhealthy status. Additional details regarding the various components and processes described above for performing an aggregated health check of a multi-tenant service container will be presented below with regard toFIGS. 1-5.

In the following detailed description, references are made to the accompanying drawings that form a part hereof, and that show, by way of illustration, specific embodiments or examples. The drawings herein are not drawn to scale. Like numerals represent like elements throughout the several figures (which may be referred to herein as a “FIG.” or “FIGS.”).

FIG. 1is a software architecture diagram showing aspects of one illustrative mechanism described herein for performing an aggregated health check of a multi-tenant service container102. It should be appreciated that multi-tenant service containers102are available for use in many development environments. For example, multi-tenant service containers102are commonly available that utilize the JAVA programming language from ORACLE CORPORATION. Examples of multi-tenant service containers102include, but are not limited to WEBSPHERE from IBM CORPORATION, SPRING FRAMEWORK from VMWARE CORPORATION, GUICE from GOOGLE CORPORATION, the PICOCONTAINER and PLEXUS projects from CODEHAUS, the FELIX, TOMCAT, TOMEE and GERONIMO projects from the APACHE SOFTWARE FOUNDATION, EQUINOX, GEMINI, JETTY and ECLIPSE from the ECLIPSE FOUNDATION, JBOSS from REDHAT CORPORATION, and GLASSFISH, WEBLOGIC, and FUSION from ORACLE CORPORATION. Although the embodiments disclosed herein are primarily presented in the context of a multi-tenant service container102, the embodiments disclosed herein might also be utilized with other types of multi-tenant execution environments.

A multi-tenant service container102can be configured to cohost a number of different tenants104A-104N. The tenants104A-104N may be services, applications, or other types of program modules. In some cases, all or a subset of the tenants104A-104N cohosted by the multi-tenant service container102provide services within a single process. In some cases, all or a subset or tenants104A-104N cohosted by the multi-tenant service container102may support a number of interdependent processes.

A load balancer106may operate as an intermediary between the clients of the tenants104A-104N of the multi-tenant service containers and one or more multi-tenant service containers102. The load balancer106communicates with the multi-tenant service containers102via a network108. The load balancer106tracks the availability of the associated multi-tenant service containers102to determine the availability of one or more tenants supported by the multi-tenant service containers102. A multi-tenant service container102may be considered unable to support customer requests for access to the services associated with one or more requested tenants if the multi-tenant service container102that supports the requested process(es) is unavailable or unhealthy, or if one of the tenants104A-104N hosted by the multi-tenant service container102that provides the use case associated with the requested tenants are unavailable or unhealthy.

In one embodiment, the multi-tenant service container102includes a container ping handler110and cohosts two or more tenants104A-104N. One mechanism that the load balancer106uses to track the availability of a use case supported by a multi-tenant service container102is to issue a container health check request112to the multi-tenant service container102via the network108. The load balancer106may issue the container health check request112to a multi-tenant service container102at a uniform resource identifier (“URI”) on the multi-tenant service container102. The container health check request112is received at the container ping handler110. In response thereto, the container ping handler110performs an aggregated health check on the multi-tenant service container102in the manner described below.

Upon receipt of the container health check request112, the container ping handler110determines whether the multi-tenant service container102is configured to handle production network traffic (e.g. actual requests for services supported by the tenants). If the container ping handler110determines that the multi-tenant service container102is not configured for production network traffic (e.g. a multi-tenant service container installed on a software development computer), the container ping handler110issues a container unhealthy status to the load balancer106. In this way, the load balancer106will not route production network traffic to a multi-tenant service container102having a container unhealthy status.

The container ping handler110includes a general container health check module114that performs a general container health check of the multi-tenant service container102. If the multi-tenant service container102fails the general container health check, the container ping handler110issues a container unhealthy status to the load balancer106.

If the multi-tenant service container102is configured for production network traffic and passes the general container health check, the container ping handler110retrieves an expected tenant list116. In one embodiment, the expected tenant list may be a list of all of the tenants104A-104N cohosted by the multi-tenant service container102. In another embodiment, the container health check request112may be associated with a specific use case supported by the multi-tenant service container102. In such a case, the expected tenant list may be a list of the tenants104A-104B cohosted by the multi-tenant service container102that support the use case associated with the container health check request112. For example, the expected tenant list116may be a subset of all of the tenants cohosted by the multi-tenant service container102. In another embodiment, the multi-tenant service container102may support a number of interdependent use cases and the expected tenant list116may include tenants that support one or more of the interdependent use cases. In another embodiment, the list of tenants in the expectant tenant list116may be defined by the container health check request112. In one embodiment, the expected tenant list116may be supplied to the multi-tenant service container102. In another embodiment, the expected tenant list116may be stored at the multi-tenant service container102. Various mechanisms may be utilized to obtain the expected tenant list116.

The container ping handler110checks tenant health metadata118associated with each of the tenants104A-104B in the expected tenant list116. A tenant104A-104B in the expected tenant list116may fail the tenant health metadata check if the tenant104A-104B has more than one live release. In another embodiment, a tenant104A-104B in the expected tenant list116may fail the tenant health metadata check if the tenant104A-104B is not hosted by the multi-tenant service container102. If any one of the tenants104A-104B on the expected tenant list116fails the tenant health metadata check, the container ping handler110issues a container unhealthy status to the load balancer106.

If none of the tenants104A-104B in the expected tenant list116fail the tenant health metadata check, the container ping handler110sequentially issues tenant health check requests120to each of the tenants104A-104B on the expected tenant list116. The tenants104A-104B each responsively issue a tenant health status122back to the container ping handler110. The tenant health status122issued by each of the tenants104A-104B is either a tenant healthy status or a tenant unhealthy status. A tenant104A-104B may issue a tenant unhealthy status if the tenant104A-104B fails a tenant ping health check.

When the container ping handler110receives the tenant health statuses122from each of the tenants104A-104B in the expected tenant list116, the container ping handler110aggregates all of the received tenant health statuses122to generate a container health status124. If all of the tenant health statuses122received from the tenants104A-104B on the expected tenant list116are tenant healthy statuses, the container ping handler110issues a container healthy status to the load balancer106. If at least one of the tenant health statuses122received from the tenants104A-104B on the expected tenant list116is a tenant unhealthy status, the container ping handler110issues a container unhealthy status to the load balancer106.

FIG. 2is a flow diagram showing a routine200that illustrates additional aspects of the mechanism shown inFIG. 1for performing an aggregated health check of a multi-tenant service container102. It should be appreciated that the logical operations described herein with respect toFIG. 2and the other FIGS. are implemented (1) as a sequence of computer implemented acts or program modules running on a computing system and/or (2) as interconnected machine logic circuits or circuit modules within the computing system. The implementation of the various components described herein is a matter of choice dependent on the performance and other requirements of the computing system. Accordingly, the logical operations described herein are referred to variously as operations, structural devices, acts, or modules. These operations, structural devices, acts, and modules may be implemented in software, in firmware, in special purpose digital logic, and any combination thereof. It should also be appreciated that more or fewer operations may be performed than shown in the FIGS. and described herein. These operations may also be performed in parallel, or in a different order than those described herein.

The routine200begins at operation202, where the multi-tenant service container102receives a container health check request112from a load balancer106. The container health check request112is received at the container ping handler110. The routine200then proceeds from operation202to operation204, where the container ping handler110determines whether the multi-tenant service container102is configured for production network traffic.

If the container ping handler110determines that the multi-tenant service container102is not configured for production network traffic, the routine200proceeds from operation204to operation206, where the container ping handler110issues a container unhealthy status to the load balancer106. If the container ping handler110determines that the multi-tenant service container102is configured for production network traffic, the routine200proceeds from operation204to operation208.

The container ping handler110includes a general container health check module114. At operation208, general container health check module114performs a general container health check of the multi-tenant service container102. If the multi-tenant service container102does not pass the general container health check, the routine200proceeds from operation208to operation206, where the container ping handler110issues a container unhealthy status to the load balancer106. If the multi-tenant service container102passes the general container health check, the routine200proceeds from operation208to operation210.

At operation210, the container ping handler110identifies the expected tenant list116for the multi-tenant service container102. As discussed above, in one embodiment the expected tenant list116may be a list of all of the tenants104A-104N cohosted by the multi-tenant service container102. In another embodiment, the container health check request112may be associated with a specific process supported by the multi-tenant service container102. In such a case, the expected tenant list116may be a list of the tenants104A-104B cohosted by the multi-tenant service container102that support the process associated with the container health check request112. For example, the expected tenant list116may be a subset of all of the tenants104A-104B cohosted by the multi-tenant service container102. In another embodiment, the multi-tenant service container102may support a number of interdependent processes and the expected tenant list116may include tenants that support one or more of the interdependent processes. In another embodiment, the list of tenants104A-104B in the expectant tenant list116may be defined by the container health check request112. In one embodiment, the expected tenant list116may be supplied to the multi-tenant service container102. In another embodiment, the expected tenant list116may be stored at the multi-tenant service container102.

From operation210, the routine200proceeds to operation212where the container ping handler110checks tenant health metadata118associated with each of the tenants104A-104B in the expected tenant list116. A tenant104A-104B in the expected tenant list116may fail the tenant health metadata check if the tenant104A-104B has more than one live release. In another embodiment, a tenant104A-104B in the expected tenant list116may fail the tenant health metadata check if the tenant104A-104B is not hosted by the multi-tenant service container102. If any one of the tenants104A-104B on the expected tenant list116fails the tenant health metadata check, the routine200proceeds from operation212to operation206where the container ping handler110issues a container unhealthy status to the load balancer106. If all of the tenants104A-104B on the expected tenant list116pass the tenant health metadata check, the routine200proceeds from operation212to operation214.

At operation214, the container ping handler110issues a tenant health check request120to each of the tenants104A-104B on the expected tenant list116. The routine200then proceeds from operation214to operation216where the container ping handler110receives a tenant health status122from each of the tenants104A-104B in the expected tenant list116. The tenant health status122is either a tenant healthy status or a tenant unhealthy status. The container ping handler110may receive a tenant unhealthy status from a tenant104A-104B if that tenant104A-104B fails a tenant ping health check.

The routine200then proceeds from operation216to operation218. When the container ping handler110receives the tenant health statuses122from each of the tenants104A-104B on the expected tenant list116, the container ping handler110aggregates all of the received tenant health statuses122to generate a container health status124. At operation218, the container ping handler110determines whether any of the received tenant health statuses122is a tenant unhealthy health status. If all of the tenant health statuses122received from the tenants104A-104B on the expected tenant list116are tenant healthy statuses, the routine200proceeds from operation218to operation220, where the container ping handler110issues a container healthy status to the load balancer106. If at least one of the tenant health statuses122received from the tenants104A-104B on the expected tenant list116is a tenant unhealthy status, the routine200proceeds from operation218to operation206where the container ping handler110issues a container unhealthy status to the load balancer106.

FIG. 3is a software architecture diagram showing aspects of one illustrative mechanism described herein for performing an aggregated health check of a multi-tenant service container102. A multi-tenant service container102can be configured to cohost a number of different tenants or applications104A-104N. In some cases, all or a subset of the tenants104A-104N cohosted by the multi-tenant service container102provide services within a single process. In some cases, all or a subset of the tenants cohosted by the multi-tenant service container102provide a number of interdependent processes.

As mentioned above, a load balancer106may operate as an intermediary between the clients of the tenants104A-104N of the multi-tenant service containers and one or more multi-tenant service containers102. The load balancer106communicates with the multi-tenant service containers102via a network108. The load balancer106tracks the availability of the associated multi-tenant service containers102to determine the availability of one or more processes supported by the multi-tenant service containers102. A multi-tenant service container102may be considered unable to support customer requests for access to the services associated with one or more requested processes if the multi-tenant service container102that supports the requested process(es) is unavailable or unhealthy, or if one of the tenants104A-104N hosted by the multi-tenant service container102that provides the services associated with the requested process(es) are unavailable or unhealthy.

In one embodiment, the multi-tenant service container102includes a container ping handler110and cohosts two or more tenants104A-104N. One mechanism that the load balancer106uses to track the availability of a process supported by a multi-tenant service container102is to issue a container health check request112to the multi-tenant service container102via the network108. The load balancer106may transmit the container health check request112to a multi-tenant service container102at a URI on the multi-tenant service container102. The container health check request112is received at the container ping handler110. In response thereto, the container ping handler110performs an aggregated health check on the multi-tenant service container102in the manner described below.

Upon receipt of container health check request112, the container ping handler110determines whether the multi-tenant service container102is configured to handle production network traffic (e.g. actual requests for services supported by the tenants). If the container ping handler110determines that the multi-tenant service container102is not configured for production network traffic (e.g. a multi-tenant service container installed on a software development computer), the container ping handler110issues a container unhealthy status to the load balancer106. In this way, the load balancer106will not route production network traffic to a multi-tenant service container102having a default container unhealthy status.

The container ping handler110includes a general container health check module114that performs a general container health check of the multi-tenant service container102. If the multi-tenant service container102fails the general container health check, container ping handler110issues a container unhealthy status to the load balancer106.

If the multi-tenant service container102is determined to be configured to handle production network traffic and passes the general container health check, the container ping handler110retrieves an expected tenant list116. In one embodiment, the expected tenant list may be a list of all of the tenants104A-104N cohosted by the multi-tenant service container102. In another embodiment, the container health check request112may be associated with a specific process supported by the multi-tenant service container102. In such a case, the expected tenant list may be a list of the tenants104A-104B cohosted by the multi-tenant service container102that support the process associated with the container health check request112. For example, the expected tenant list116may be a subset of all of the tenants cohosted by the multi-tenant service container102. In another embodiment, the multi-tenant service container102may support a number of interdependent processes and the expected tenant list116may include tenants that support one or more of the interdependent processes. In another embodiment, the list of tenants in the expectant tenant list116may be defined by the container health check request112. In one embodiment, the expected tenant list116may be supplied to the multi-tenant service container102. In another embodiment, the expected tenant list116may be stored at the multi-tenant service container102. Various mechanisms may be utilized to obtain the expected tenant list116.

The container ping handler110checks tenant health metadata118associated with each of the tenants104A-104B in the expected tenant list116. A tenant104A-104B in the expected tenant list116may fail the tenant health metadata check if the tenant104A-104B has more than one live release. In another embodiment, a tenant104A-104B in the expected tenant list116may fail the tenant health metadata check if the tenant104A-104B is not hosted by the multi-tenant service container102. If any one of the tenants104A-104B on the expected tenant list116fails the tenant health metadata check, the container ping handler110issues a container unhealthy status to the load balancer106.

If all of the tenants104A-14B pass the tenant health metadata check, the container ping handler110creates a container status request/response object302in response to the container health check request112. The container ping handler110creates a tenant specific decorating request/response object304based on the container status request/response object302for a tenant104A in the expected tenant list116. The container ping handler110isolates the underlying container status request/response object302from the tenant specific decorating request/response object304by resetting the internal status of the underlying container status request/response object302. The internal status of the underlying container status request/response object302that is reset by the container ping handler110may, for example, include one or more of a Status, OutputStream and PrinterWriter internal statuses. The container ping handler110sends the tenant specific decorating request/response object304to the tenant104A and receives a processed tenant specific decorating request/response object306from the tenant104. The received processed tenant specific decorating request/response object306indicates the tenant health status122of the associated tenant104A. The tenant health status122consists of either a tenant healthy status or a tenant unhealthy status. The container ping handler110repeats the process described above for each of the tenants104A-104B in the expected tenant list116.

The container ping handler110processes the container status request/response object302based on an aggregation of the plurality of processed tenant specific decorating request/response objects304and generates a container health status124based on the processed container status request/response object302. If all of the tenant health statuses122received from the tenants104A-104B on the expected tenant list116are tenant healthy statuses, the container ping handler110issues a container healthy status to the load balancer106. If at least one of the tenant health statuses122received from the tenants104A-104B on the expected tenant list116is a tenant unhealthy status, container ping handler110issues a container unhealthy status to the load balancer106.

FIG. 4is a flow diagram showing a routine400that illustrates additional aspects of the mechanism shown inFIG. 1for performing an aggregated health check of a multi-tenant service container102. The routine400begins at operation402, where the multi-tenant service container102receives a container health check request112from a load balancer106. The container health check request112is received at the container ping handler110. The routine400then proceeds from operation402to operation404, where the container ping handler110determines whether the multi-tenant service container102is configured for production network traffic.

If the container ping handler110determines that the multi-tenant service container102is not configured for production network traffic, the routine400proceeds from operation404to operation406, where the container ping handler110issues a container unhealthy status to the load balancer106. If the container ping handler110determines that the multi-tenant service container102is configured for production network traffic, the routine400proceeds from operation404to operation408.

The container ping handler110includes a general container health check module114. At operation408, general container health check module114performs a general container health check of the multi-tenant service container102. If the multi-tenant service container102does not pass the general container health check, the routine400proceeds from operation408to operation406, where the container ping handler110issues a container unhealthy status to the load balancer106. If the multi-tenant service container102passes the general container health check, the routine400proceeds from operation408to operation410.

At operation410, the container ping handler110identifies the expected tenant list116for the multi-tenant service container102. As discussed above, in one embodiment the expected tenant list116may be a list of all of the tenants104A-104N cohosted by the multi-tenant service container102. In another embodiment, the container health check request112may be associated with a specific process supported by the multi-tenant service container102. In such a case, the expected tenant list116may be a list of the tenants104A-104B cohosted by the multi-tenant service container102that support the process associated with the container health check request112. For example, the expected tenant list116may be a subset of all of the tenants104A-104B cohosted by the multi-tenant service container102. In another embodiment, the multi-tenant service container102may support a number of interdependent processes and the expected tenant list116may include tenants that support one or more of the interdependent processes. In another embodiment, the list of tenants104A-104B in the expectant tenant list116may be defined by the container health check request112. In one embodiment, the expected tenant list116may be supplied to the multi-tenant service container102. In another embodiment, the expected tenant list116may be stored at the multi-tenant service container102.

From operation410, the routine400proceeds to operation412where the container ping handler110checks tenant health metadata118associated with each of the tenants104A-104B in the expected tenant list116. A tenant104A-104B in the expected tenant list116may fail the tenant health metadata check if the tenant104A-104B has more than one live release. In another embodiment, a tenant104A-104B in the expected tenant list116may fail the tenant health metadata check if the tenant104A-104B is not hosted by the multi-tenant service container102. If any one of the tenants104A-104B on the expected tenant list116fails the tenant health metadata check, the routine400proceeds from operation412to operation406where the container ping handler110issues a container unhealthy status to the load balancer106. If all of the tenants104A-104B on the expected tenant list116pass the tenant health metadata check, the routine400proceeds from operation412to operation414.

At operation414, he container ping handler110creates a container status request/response object302in response to the container health check request112. The container ping handler110creates a tenant specific decorating request/response object304based on the container status request/response object302for a tenant104A in the expected tenant list116. The container ping handler110isolates the underlying container status request/response object302from the tenant specific decorating request/response object304by resetting the internal status of the underlying container status request/response object302. The internal status of the underlying container status request/response object302that is reset by the container ping handler110may, for example, include one or more of a Status, OutputStream and PrinterWriter internal statuses. The routine400then proceeds from operation414to operation416.

At operation416, the container ping handler110sends the tenant specific decorating request/response object304to the tenant104A and at operation418, the container ping handler110receives a processed tenant specific decorating request/response object306from the tenant104A. The received processed tenant specific decorating request/response object306indicates the tenant health status122of the associated tenant104A. The tenant health status122consists of either a tenant healthy status or a tenant unhealthy status. The container ping handler110receives a tenant unhealthy status from a tenant104A if that tenant104A has more than one live release.

The routine400then proceeds from operation418to operation420, where the container ping handler110determines whether all of the tenants104A-104B on the expected tenant list116have been queried regarding their tenant health status122. If the container ping handler110determines that all of the tenants104A-104B on the expected tenant list116have not been queried, the routine400proceeds from operation420to operation414where the container ping handler110repeats operations414,416and418with the next tenant104B on the expected tenants list114. If the container ping handler110determines that all of the tenants104A-104B on the expected tenant list116have been queried, the routine400proceeds from operation420to operation422.

At operation422, the container ping handler110processes the container status request/response object302based on an aggregation of all of the tenant health statuses122received from the tenants104A-104B via the processed tenant specific request/response decorating objects306on the expected tenant list116and generates a container health status124based on the processed container status request/response object302. If all of the tenant health statuses122received from the tenants104A-104B on the expected tenant list116are tenant healthy statuses, the routine400proceeds from operation422to operation424and the container ping handler110processes the container status request/response object302accordingly and issues a container healthy status based on the processed container status request/response object to the load balancer106.

If at least one of the tenant health statuses122received from the tenants104A-104B on the expected tenant list116is a tenant unhealthy status, the routine400proceeds from operation422to operation406where the container ping handler110processes the container status request/response object302accordingly and issues a container unhealthy status based on the processed container status request/response object302to the load balancer106.

FIG. 5shows an example computer architecture for a computer500capable of executing the program components described above for performing an aggregated health check of a multi-tenant service container102. The computer architecture shown inFIG. 5illustrates a conventional server computer, workstation, desktop computer, laptop, tablet, network appliance, personal digital assistant (“PDA”), e-reader, digital cellular phone, or other computing device, and may be utilized to execute any aspects of the software components presented herein.

The chipset506provides an interface between the CPUs504and the remainder of the components and devices on the baseboard502. The chipset506may provide an interface to a random access memory (“RAM”)508, used as the main memory in the computer500. The chipset506may further provide an interface to a computer-readable storage medium such as a read-only memory (“ROM”)510or non-volatile RAM (“NVRAM”) for storing basic routines that help to startup the computer500and to transfer information between the various components and devices. The ROM510or NVRAM may also store other software components necessary for the operation of the computer500in accordance with the embodiments described herein.

The computer500may operate in a networked environment using logical connections to remote computing devices and computer systems through a network, such as the local area network520. The chipset506may include functionality for providing network connectivity through a NIC512, such as a gigabit Ethernet adapter. The NIC512is capable of connecting the computer500to other computing devices over the network520. It should be appreciated that multiple NICs512may be present in the computer500, connecting the computer to other types of networks and remote computer systems.

The computer500may be connected to a mass storage device518that provides non-volatile storage for the computer. The mass storage device518may store system programs, application programs, other program modules, and data, which have been described in greater detail herein. The mass storage device518may be connected to the computer500through a storage controller514connected to the chipset506. The mass storage device518may consist of one or more physical storage units. The storage controller514may interface with the physical storage units through a serial attached SCSI (“SAS”) interface, a serial advanced technology attachment (“SATA”) interface, a fiber channel (“FC”) interface, or other type of interface for physically connecting and transferring data between computers and physical storage units.

In addition to the mass storage device518described above, the computer500may have access to other computer-readable storage media to store and retrieve information, such as program modules, data structures, or other data. It should be appreciated by those skilled in the art that computer-readable storage media can be any available media that provides for the storage of non-transitory data and that may be accessed by the computer500.

The mass storage device518may store an operating system522utilized to control the operation of the computer500. According to one embodiment, the operating system comprises the LINUX operating system. According to another embodiment, the operating system comprises the WINDOWS® SERVER operating system from MICROSOFT Corporation. According to further embodiments, the operating system may comprise the UNIX or SOLARIS operating systems. It should be appreciated that other operating systems may also be utilized. The mass storage device518may store other system or application programs and data utilized by the computer500, such the multi-tenant service container102, the container ping handler110, and/or any of the other software components and data described above. The mass storage device518might also store other programs and data not specifically identified herein.

In one embodiment, the mass storage device518or other computer-readable storage media is encoded with computer-executable instructions which, when loaded into the computer500, transforms the computer from a general-purpose computing system into a special-purpose computer capable of implementing the embodiments described herein. These computer-executable instructions transform the computer500by specifying how the CPUs504transition between states, as described above. According to one embodiment, the computer500has access to computer-readable storage media storing computer-executable instructions which, when executed by the computer500, perform the various routines described above with regard toFIGS. 2 and 4. The computer500might also include computer-readable storage media for performing any of the other computer-implemented operations described herein.

The computer500may also include one or more input/output controllers516for receiving and processing input from a number of input devices, such as a keyboard, a mouse, a touchpad, a touch screen, an electronic stylus, or other type of input device. Similarly, the input/output controller516may provide output to a display, such as a computer monitor, a flat-panel display, a digital projector, a printer, a plotter, or other type of output device. It will be appreciated that the computer500may not include all of the components shown inFIG. 5, may include other components that are not explicitly shown inFIG. 5, or may utilize an architecture completely different than that shown inFIG. 5.

Based on the foregoing, it should be appreciated that technologies for modification of program code for execution in multi-tenant and/or distributed computing environments have been presented herein. Moreover, although the subject matter presented herein has been described in language specific to computer structural features, methodological acts, and computer readable media, it is to be understood that the invention defined in the appended claims is not necessarily limited to the specific features, acts, or media described herein. Rather, the specific features, acts, and mediums are disclosed as example forms of implementing the claims.