Automatic generation of affinity and anti-affinity rules

Abstract

One embodiment provides a computer-implemented method that includes receiving an application to be deployed in a container-based environment; obtaining a specification of the application that includes information about portions of the application that are contained within a given container; extracting portion information corresponding to associations and interferences between different portions of the application; identifying affinity indicators and anti-affinity indicators for the portions of the application, where the affinity indicators are based on associations between the different portions of the application and the anti-affinity indicators are based on interferences between the different portions of the application; and constructing affinity and anti-affinity rules for the container by combining the affinity indicators to construct affinity rules and combining the anti-affinity indicators to construct anti-affinity rules.

Description

[Background technology]

[0001] With the proliferation of remote computing or service environments, e.g., remote network environments, cloud computing environments, etc., more users and entities are migrating the hosting of their applications and other services to service environments. By migrating the hosting of their applications and other services to service environments, users and other entities can reduce the use of internal resources (e.g., infrastructure, computing resources, human resources, etc.) and reduce other costs associated with the applications and other services. In addition, because service environments typically have many more resources, specifically computing resources, than a user or entity has locally, users or entities can scale applications hosted in a service environment. Thus, the use of service environments is very attractive to application entities. Summary of the Invention

[0002] In summary, one aspect of the invention provides a computer-implemented method including receiving an application to be deployed in a container-based environment, the application being divided into containers containing portions of the application; obtaining a specification of the application including information about portions of the application that are contained within a given container; extracting from the specification portion information corresponding to connections and interferences between different portions of the application; identifying affinity and anti-affinity indicators for the portions of the application from the portion information, the affinity indicators being based on connections between the different portions of the application and the anti-affinity indicators being based on interferences between the different portions of the application; and constructing affinity and anti-affinity rules for the container by combining the affinity indicators to construct affinity rules and combining the non-affinity indicators to construct anti-affinity rules, the affinity rules identifying containers hosted by a same host in the container-based environment and the anti-affinity rules identifying containers hosted by different hosts in the container-based environment.

[0003] Another aspect of the invention includes at least one processor and a computer readable storage medium having computer readable program code executable by the at least one processor, the computer readable program code including code for receiving an application to be deployed in a container based environment, the application being partitioned into containers that include portions of the application, the computer readable program code including code for obtaining a specification of the application that includes information regarding portions of the application that are included within a given container, the computer readable program code including code for extracting from the specification portion information corresponding to associations between and interferences between different portions of the application, and the computer readable program code including code for extracting from the portion information portion information corresponding to associations between and interferences between different portions of the application. In one embodiment, the apparatus further comprises code for identifying affinity and anti-affinity indicators for the containers, the affinity indicators being based on associations between different portions of the application and the non-affinity indicators being based on interference between different portions of the application; and the computer readable program code includes code for constructing affinity and anti-affinity rules for the containers by combining the affinity indicators to construct the affinity rules and combining the non-affinity indicators to construct the non-affinity rules, the affinity rules identifying containers hosted by the same host in the container-based environment and the non-affinity rules identifying containers hosted by different hosts in the container-based environment.

[0004] Additional aspects of the invention include a computer readable storage medium having computer readable program code embodied therein, the computer readable program code executable by a processor, the computer readable program code including code for receiving an application to be deployed in a container based environment, the application being partitioned into containers containing portions of the application, the computer readable program code including code for obtaining a specification of the application including information regarding portions of the application that are contained within a given container, the computer readable program code including code for extracting from the specification portion information corresponding to associations between and interferences between different portions of the application, and the computer readable program code including code for extracting from the portion information affinities of the portions of the application. and code for identifying affinity indicators and anti-affinity indicators for the container, the affinity indicators being based on associations between different portions of the application and the non-affinity indicators being based on interference between different portions of the application; and the computer readable program code comprising code for constructing affinity rules and anti-affinity rules for the container by combining the affinity indicators to construct the affinity rules and combining the non-affinity indicators to construct the non-affinity rules, the affinity rules identifying containers hosted by the same host in the container-based environment and the non-affinity rules identifying containers hosted by different hosts in the container-based environment.

[0005] For a better understanding of the exemplary embodiments of the present invention, together with other and further features and advantages thereof, reference is made to the following description taken in conjunction with the accompanying drawings, the scope of the claimed embodiments of the invention being set forth in the appended claims. [Brief description of the drawings]

[0006] [Figure 1]FIG. 1 illustrates a cloud computing environment according to one embodiment of the present invention. [Diagram 2] FIG. 2 illustrates abstraction model layers according to one embodiment of the present invention. [Diagram 3] FIG. 1 illustrates a method for automatically generating affinity and anti-affinity rules for an application that is split into containers by extracting affinity and anti-affinity indicators from information corresponding to the parts contained within the containers. [Figure 4] FIG. 1 illustrates an overall system architecture for automatically generating affinity and anti-affinity rules for applications split into containers by extracting affinity and anti-affinity indicators from information corresponding to the parts contained within the containers. [Diagram 5] FIG. 1 is a diagram showing a computer system. DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

[0007] It will be readily understood that the components of the embodiments of the present invention as generally described and illustrated herein can be arranged and designed in a wide variety of different configurations in addition to the exemplary embodiments described. Thus, the following more detailed description of the embodiments of the present invention as depicted in the figures is not intended to limit the scope of the embodiments of the present invention as claimed, but is merely representative of exemplary embodiments of the invention.

[0008] References throughout this specification to "one embodiment" or "an embodiment" (and the like) mean that a particular feature, structure, or characteristic described in connection with that embodiment is included in at least one embodiment of the invention. Thus, the appearances of phrases such as "in one embodiment" or "in an embodiment" in various places throughout this specification do not necessarily all refer to the same embodiment.

[0009] Furthermore, the described features, structures, or characteristics may be combined in any suitable manner in at least one embodiment. In the following description, numerous specific details are provided to provide a thorough understanding of embodiments of the invention. However, one skilled in the art may readily recognize that embodiments of the invention may be practiced without at least one of those specific details, or may be practiced using other methods, components, materials, etc. In other instances, well-known structures, materials, or operations are not shown or described in detail to avoid obscuring aspects of the invention.

[0010] The exemplary embodiments of the present invention can be better understood by referring to the figures. The following description is intended to be merely exemplary and merely illustrates certain selected exemplary embodiments of the present invention claimed herein. It should be understood that the flowcharts and block diagrams in the figures illustrate the architecture, functionality, and operation of possible implementations of systems, apparatus, methods, and computer program products according to various embodiments of the present invention. In this regard, each block in the flowchart or block diagram may represent a module, segment, or portion of code that includes at least one executable instruction for implementing a specified logical function.

[0011] It should also be noted that in some alternative implementations, the functions noted in the blocks may occur out of the order depicted. For example, two blocks shown in succession may in fact be executed substantially simultaneously, or the blocks may possibly be executed in the reverse order, depending on the functionality involved. It should also be noted that each block of the block diagrams and / or flowchart illustrations, and combinations of blocks in the block diagrams and / or flowchart illustrations, may be implemented by a dedicated hardware-based system that performs the specified functions or acts or executes a combination of dedicated hardware and computer instructions.

[0012] Specific reference is made herein below to Figures 1-5. It should be understood that the processes, configurations, and products broadly illustrated therein may essentially be performed in or in accordance with any suitable computer system or set of computer systems, which may include, as an illustrative and non-limiting example, a system or server such as that shown at 12' in Figure 5. In accordance with an exemplary embodiment, most, if not all, of the process steps, components, and outputs discussed with respect to Figures 1-4 may be performed by or utilized by one or more processing units and system memories such as those shown at 16' and 28' in Figure 5, respectively, whether in a server computer, a client computer, a node computer in a distributed network, or any combination thereof.

[0013] Although this disclosure includes detailed descriptions of cloud computing, it should be understood that implementation of the teachings recited herein is not limited to a cloud computing environment. Rather, embodiments of the invention may be implemented in conjunction with any other type of computing environment now known or later developed.

[0014] Cloud computing is a model of service delivery for enabling convenient, on-demand network access to a shared pool of configurable computing resources (e.g., networks, network bandwidth, servers, processing, memory, storage, applications, virtual machines, and services) that can be rapidly provisioned and released with minimal administrative effort or interaction with a service provider. The cloud model may include at least five characteristics, at least three service models, and at least four deployment models.

[0015] Its features are as follows.

[0016] On-Demand Self-Service: Cloud consumers can unilaterally provision computing capacity, such as server time and network storage, automatically as needed, without the need for human interaction with the provider of the service.

[0017] Broad Network Access: Capabilities are available over the network and are accessed through standard mechanisms that facilitate use by heterogeneous thin or thick client platforms (e.g., cell phones, laptops, and PDAs).

[0018] Resource Pooling: Pooling provider computing resources to serve multiple consumers using a multi-tenant model where various physical and virtual resources are dynamically allocated and reallocated according to demand. Consumers generally have no control over or knowledge of the exact location of the resources provided to them, although there is a sense of location independence in that the location may be identifiable at a higher level of abstraction (e.g., country, state, or data center).

[0019] Rapid Elasticity: Capacity can be rapidly and elastically provisioned, sometimes automatically, to quickly scale out and rapidly release to quickly scale in. To the consumer, provisionable capacity often appears to be unlimited and can be purchased in any quantity at any time.

[0020] Metered Services: Cloud systems leverage metering capabilities at some level of abstraction appropriate to the type of service (e.g., storage, processing, bandwidth, and active user accounts) to automatically control and optimize resource usage. Resource usage can be monitored, controlled, and reported to provide transparency to both providers and consumers of the services utilized.

[0021] The service model is as follows:

[0022] Software as a Service (SaaS): The capability offered to the consumer is to use the provider's applications running on a cloud infrastructure. The applications are accessible from a variety of client devices through thin-client interfaces such as web browsers (e.g., web-based email). The consumer has no management or control over the underlying cloud infrastructure, including networks, servers, operating systems, storage, or even individual application features, with the possible exception of limited user-specific application configuration settings.

[0023] Platform as a Service (PaaS): The capability offered to a consumer is to deploy applications that the consumer creates or acquires, written using programming languages ​​and tools supported by the provider, onto a cloud infrastructure. The consumer does not manage or control the underlying cloud infrastructure, including networks, servers, operating systems, or storage, but does control the deployed applications and possibly the application hosting environment configuration.

[0024] Infrastructure as a Service (IaaS): The ability offered to consumers is to provision processing, storage, network, and other basic computing resources onto which the consumer can deploy and run any software, which may include operating systems and applications. The consumer does not manage or control the underlying cloud infrastructure, but does control the operating systems, storage, deployed applications, and possibly limited control over selected networking components (e.g., host firewalls).

[0025] The deployment model is as follows:

[0026] Private Cloud: The cloud infrastructure is operated exclusively for an organization. It can be managed by the organization or a third party and can exist on-premise or off-premise.

[0027] Community Cloud: Cloud infrastructure is shared by several organizations to support a particular community with common concerns (e.g., mission, security requirements, policies, and compliance considerations). It may be managed by the organization or a third party and may exist on-premise or off-premise.

[0028] Hybrid Cloud: A cloud infrastructure is a composite of two or more clouds (private, community, or public) that remain unique entities but are joined by standardized or proprietary technologies that enable data and application portability (e.g., cloud bursting for load balancing between clouds).

[0029] Cloud computing environments are service-oriented with an emphasis on statelessness, low coupling, modularity, and semantic interoperability. At the core of cloud computing is an infrastructure that includes a network of interconnected nodes.

[0030] Referring now to FIG. 1, an exemplary cloud computing environment 50 is shown. As shown, the cloud computing environment 50 includes one or more cloud computing nodes 10 with which local computing devices used by cloud consumers, such as, for example, a personal digital assistant (PDA) or cell phone 54A, a desktop computer 54B, a laptop computer 54C, or an automobile computer system 54N, or combinations thereof, may communicate. The nodes 10 may communicate with each other. They may be physically or virtually grouped (not shown), for example, in one or more networks, such as the private, community, public, or hybrid clouds described above, or combinations thereof. This enables the cloud computing environment 50 to provide infrastructure-as-a-service, platform-as-a-service, or software-as-a-service, or combinations thereof, without the cloud consumer having to maintain resources on a local computing device. It should be understood that the types of computing devices 54A-N illustrated in FIG. 1 are intended to be exemplary only, and that the computing node 10 and cloud computing environment 50 can communicate with any type of computerized device via any type of network or network-addressable connection (e.g., using a web browser) or both.

[0031] Referring now to Figure 2, a set of functional abstraction layers provided by cloud computing environment 50 (Figure 1) is shown. It should be understood in advance that the components, layers, and functions shown in Figure 2 are intended to be exemplary only, and embodiments of the present invention are not limited thereto. As shown, the following layers and corresponding functions are provided:

[0032] The hardware and software layer 60 includes hardware and software components. Examples of hardware components include mainframes 61, RISC (reduced instruction set computer) architecture based servers 62, servers 63, blade servers 64, storage devices 65, and networks and networking components 66. In some embodiments, the software components include network application server software 67 and database software 68.

[0033] The virtualization layer 70 provides an abstraction layer from which the following examples of virtual entities may be provided: virtual servers 71, virtual storage 72, virtual networks including virtual private networks 73, virtual applications and operating systems 74, and virtual clients 75.

[0034] In one example, the management layer 80 may provide the following functions: Resource provisioning 81 provides dynamic procurement of computing and other resources utilized to execute tasks within the cloud computing environment. Metering and pricing 82 provides cost tracking as resources are utilized within the cloud computing environment and accounting or billing for the consumption of these resources. In one example, these resources may include application software licenses. Security provides identity verification of cloud consumers and tasks as well as protection for data and other resources. User portal 83 provides consumers and system administrators with access to the cloud computing environment. Service level management 84 provides allocation and management of cloud computing resources such that requested service levels are met. Service level agreement (SLA) planning and fulfillment 85 provides advance arrangement and procurement of cloud computing resources anticipated to be required in the future according to SLAs.

[0035] The workload layer 90 provides examples of functionality for which a cloud computing environment may be utilized. Examples of workloads and functions that may be provided from this layer include mapping and navigation 91, software development and lifecycle management 92, virtual classroom instructional delivery 93, data analytics processing 94, transaction processing 95, and service hosting 96.

[0036] When an application is deployed to a service environment controlled by an entity other than the development entity, the service environment entity controls many different aspects of the application with respect to the service environment. For example, the service environment entity controls where the application is located in the service environment, which resources are allocated to the application, etc. In the context of this application, a service environment refers to a service environment that may be on-premise or in a private cloud, as well as a service environment that is hosted at a completely remote location. Rather, the term service environment refers to a service environment where the application entity does not have full knowledge or control of the deployment environment and other applications that may be hosted within the service environment. Problems can arise when an application is split into different parts, for example, into containers, where each container contains a part of the application. When deployed to a service environment, the service environment entity selects the location of each of these different parts or containers on the service environment. The service environment entity also selects which resources to allocate to each container, which containers to group together (e.g., in a cluster, in a pod, etc.), etc.

[0037] Since the service environment entities have no knowledge of the application, these choices are arbitrary and are based on attributes of the service environment, not on attributes of the application. This arbitrary choice may cause problems with the performance of the entire application, such as reducing the processing speed and accuracy of the application, causing interference between application parts, reducing the redundancy of the desired application, etc. These problems arise because different application parts should be hosted by the same host because they may be related, or should be hosted by different hosts because they may cause interference with other application parts.

[0038] One technique for addressing these issues is to allow application entities to specify affinity and anti-affinity rules. Affinity rules identify application parts or containers that should be hosted by the same host in the service environment. Anti-affinity rules identify application parts or containers that should be hosted by different hosts in the service environment. By specifying these affinity and anti-affinity rules, the service environment knows which application parts or containers should be kept together or kept separate from each other. However, application entities may not know which application parts or containers should be kept together or kept separate from each other. Thus, while the ability to specify affinity and anti-affinity rules is useful, this ability is not very useful if the application entities do not know what rules should be specified, which is a very common problem.

[0039] Accordingly, one embodiment provides a system and method for automatically generating affinity and anti-affinity rules for a containerized application by extracting affinity and anti-affinity indicators from information corresponding to the parts contained within the containers. The system receives an application to be deployed into a container-based environment, e.g., a services environment. As the application is deployed into the container-based environment, the application is partitioned into containers that include different parts of the application. The system obtains a specification of the application that identifies information about each part of the application that is contained within a container. This information may include, for example, interactions between the application parts, relationships of the application parts, constraints of the application parts, fault tolerance requirements, etc.

[0040] From the specification, the system can extract information about the parts or containers, more specifically, the associations between different parts of the application, and the interferences between different parts of the application. For example, the system may identify that two parts contained within different containers frequently interact. As another example, the system may identify that two parts contained within different containers require large amounts of the same processing resources (e.g., memory, storage, processor, hardware, etc.). Thus, from the extracted information about the parts or containers, the system can identify affinity and anti-affinity indicators. Affinity indicators indicate parts of the application that work with or depend on other parts of the application. Non-affinity indicators indicate parts of the application that compete or interfere with other parts of the application. From the affinity and anti-affinity indicators, the system can build affinity and anti-affinity rules for the containers, thereby providing an automated technique for identifying and building affinity and anti-affinity rules instead of relying on application entities to manually identify these rules.

[0041] Such a system provides a technical improvement over current systems for deploying applications in container-based environments. Rather than requiring an application entity to manually specify affinity and anti-affinity rules, the described systems and methods can automatically identify and generate affinity and anti-affinity rules from an input specification of the application. The described systems and methods can extract information corresponding to each application or container from the input specification and extract affinity and anti-affinity indicators from this information. The affinity and anti-affinity indicators can be grouped to construct affinity and anti-affinity rules. Thus, rather than requiring an application entity to manually specify affinity and anti-affinity rules that may be unknown to the application entity, the described systems can make these specifications automatically. Thus, the described systems and methods provide a system that generates affinity and anti-affinity rules more accurately than manual techniques. More precise affinity and anti-affinity rules enable applications to perform better than the imprecise or non-existent affinity and anti-affinity rules offered by conventional techniques.

[0042] FIG. 3 illustrates a method for automatically generating affinity and anti-affinity rules for a containerized application by extracting affinity and anti-affinity indicators from information corresponding to the portions contained within the container. At 301, the system receives an application to be deployed to a container-based environment. The deployment may include deploying the entire application to a new cluster or pod within the container-based environment, deploying one or more processes or services of the application into a container-based environment that already hosts other services, updating an already deployed application with affinity and anti-affinity rules, etc. Receiving the application may include any technique for obtaining the application, including, but not limited to, a user uploading or otherwise providing the application to the system or service environment, the system or service environment accessing the location of the application, a user providing a link or pointer to the application, etc. The described systems and methods may be standalone applications, may be add-ons or supplemental applications to the service environment, may be executed locally prior to deploying the application to the service environment, may be executed by the service environment, etc.

[0043] As applications are deployed in a container-based environment, the application is partitioned into containers, with each container containing one or more parts or processes of the application. For ease of reading, the term part is used throughout this specification to refer to one or more parts of an application contained within a single container, and the term part is not intended to limit the disclosure to a single part or process within each container. In other words, a container may contain more than one process or part of an application, but is referred to as a part for ease of reading. Applications may be partitioned into containers by the entity that developed, owns, or otherwise controls the application, referred to herein as the application entity.

[0044] Upon receiving the application, the system obtains a specification of the application at 302. The specification includes information about each part of the application within a container. For example, the specification identifies the processes represented by the parts and contained within the containers, the resources required to run the parts, the number of copies of the parts that need to be run in the service environment, etc. In other words, the specification provides information to identify the processes and the constraints and / or requirements of the processes contained within each container. The specification may be in the form of source code, developer comments, configuration files, etc., or a combination thereof. Generally, all containers of a single application are considered to be contained within a single specification. However, the described system and method allows for collecting information about containers from multiple specifications, if applicable. Nevertheless, the term specification is used throughout this specification for ease of reading, but is not intended to limit the scope of this disclosure to a single specification.

[0045] At 303, the system extracts partial information from the specification. The partial information corresponds to associations between different parts of the application, e.g., interactions between the parts, relationships or dependencies between the parts, or both, common resource requirements or constraints between the parts, etc. The partial information may also identify associations between different applications and / or services hosted in the environment, e.g., applications not related to or created by the application entity. The partial information may also identify interferences between different parts of the application, or between the application and other applications or services co-hosted on the environment, e.g., conflicting resource requirements or constraints, fault tolerance requirements, placement constraints, etc. In extracting the interactions, the system may generate or access a topology of connections between parts of the application.

[0046] A placement constraint may identify that a particular part should be placed at a location on the service environment that can satisfy the part's particular requirements or preferences, e.g., particular hardware requirements / preferences, particular software requirements / preferences, particular processing requirements / preferences, etc. A fault tolerance requirement may identify that instances of the part should be hosted on different hosts in the service environment to ensure redundancy in the event of a failure or outage of a remote service environment part. For example, it may be identified that three instances or copies of the part should be running in the service environment, and that all three should be hosted on separate or different hosts to prevent a complete loss of the service represented by that part in the event of a failure or outage of the part of the service environment.

[0047] From the extracted portion information, the system determines whether affinity indicators and anti-affinity indicators can be identified for portions of the application at 304. The affinity indicators indicate portions that should be kept together or hosted by the same host in the service environment. Thus, the affinity indicators are based on associations between different portions of the application. The anti-affinity indicators indicate portions that should be kept separately or hosted by different hosts in the service environment. Thus, the anti-affinity indicators are based on interferences between different portions of the application. Additionally, the system can identify pod design indicators from the extracted portion information. A pod design is a cluster or grouping of portions on a service environment system. Several non-exhaustive examples of identifying affinity indicators and / or pod design indicators from the portion information follow below. However, these are merely examples and other techniques are contemplated and possible.

[0048] As a first example of identifying affinity indicators, the system may identify interactions between parts that would indicate that some parts communicate with each other. The system may also determine the frequency of the communication to determine the strength of the affinity indicator. To identify the interactions, the system may access service interactions and network configurations. Within the service interactions, there may be defined links that connect one application part to another application part. Such defined links suggest affinity between the linked parts. The user may also define networks between parts of the application. A network identifies a group of parts, all connected together to enable communication between the parts in the network, but isolated from other parts that are not on the network. Thus, the network suggests affinity between the parts contained within the defined network. Information corresponding to the ports may be used to infer the type of service the parts are running on, and as an indicator of the strength of the links with respect to affinity.

[0049] Other examples of affinity indicators are relationships and / or dependencies between parts. Certain terms used within a specification may indicate relationships or dependencies between parts. For example, certain terms may indicate that certain parts depend on other parts. The system may also identify service relationships from files. For example, multiple service definitions in a single file may be an indicator of affinity, especially if the configuration is split across many files. Some files may indicate service function chains, which are indicators of close service interactions and therefore affinity between those services or parts. These files may also be indicators that groups of parts should be kept together in the same pod. For example, parts represented in related files are a pod design indicator that those parts should be grouped or clustered together.

[0050] Another example of an affinity indicator is storage requirements between parts. Parts that access a shared storage volume may indicate affinity between the parts. These parts are also candidates for being placed together in the same cluster or pod so that only a single pod accesses the shared storage volume, which reduces the number of remote reads that would otherwise occur by placing the parts in different pods. Also, storage or other resource requirements can be anti-affinity indicators. The system may identify parts that have large resource requirements, for example, memory requirements, processing requirements, storage requirements, etc. If multiple parts have the same large resource requirements, this can be an anti-affinity indicator. For example, if two parts that otherwise have no affinity or have some strong affinity both require a lot of memory resources, hosting these parts on the same host may bring down memory resources and degrade the performance of not only these parts but also any other parts hosted by the same host.

[0051] Other examples of affinity or anti-affinity indicators are placement constraints. Placement constraints identify special requirements or preferences (e.g., hardware requirements, software requirements, processing requirements, etc.) needed or required by parts that can only be satisfied by certain hosts in the service environment. These parts can therefore only be placed in locations in the service environment that can satisfy these requirements. Placement constraints may include hard constraints, which are requirements, and soft constraints, which are preferences. For example, a part that requires certain hardware resources to function is a hard constraint or requirement, while a part that performs better with certain hardware resources is a soft constraint or preference. Additionally, parts with the same placement constraints may indicate affinity, while parts that are recommended to be separated may indicate anti-affinity.

[0052] A final example of an anti-affinity indicator is a fault tolerance requirement. An application may require multiple copies, replicas, or instances of a particular part to run in the service environment. One reason for multiple copies is to prevent the service corresponding to a part from becoming unavailable in the event of a failure or outage. In other words, the service corresponding to the part may be a critical service that needs to be operational to keep the application operational. Thus, the system may specify that multiple copies of a service are running to ensure the operation of the application. Thus, to better ensure that at least one copy will function in the event of a failure or outage in the service environment, these copies should not be hosted on the same host. Thus, an indication of replicas or copies is an anti-affinity indicator between the copies or instances.

[0053] If the affinity and anti-affinity indicators cannot be identified at 304, the system may inform the user at 305. The user may then provide additional input information to enable the indicators to be identified or may manually provide affinity and anti-affinity rules. On the other hand, if the indicators can be identified at 304, the system may automatically construct affinity and anti-affinity rules based on the affinity and anti-affinity indicators. To construct the rules, the system may combine the affinity indicators into affinity rules that identify containers or portions that are hosted by the same host in the container-based environment. Also, the system may combine the anti-affinity indicators into anti-affinity rules that identify containers or portions that should be kept separate or hosted by different hosts in the container-based environment. Additionally, the system may combine the pod design indicators into pod design rules that indicate portions of an application that should be included within the same pod in the container-based environment to construct a pod design for the application in the container-based environment.

[0054] These rules can be constructed by combining indicators by one or a combination of approaches. Several approaches are described below. However, this is a non-exhaustive list of examples and other approaches are possible and contemplated. The first approach involves a rule-based approach. In this approach, a rule is created that indicates that if an affinity or anti-affinity indicator is present, then parts with affinity or anti-affinity are placed together or kept separately, respectively. Rules can also be made more complex in that a certain number of affinity or anti-affinity indicators must be present for a decision regarding container placement to be made. Additionally, weights can be added to the indicators. For example, certain indicators may have a greater weight than other indicators. The system can then determine that a decision regarding placement can be made if the weight of the indicator meets or exceeds a certain threshold.

[0055] Another approach is to utilize precedence or priority rules for determining part placement. A user, application entity, the described system, etc. may assign a particular precedence or priority to a particular affinity or anti-affinity indicator. Thus, if one of these indicators is present, the system will precede or prioritize that indicator and take an action regarding placement based on that indicator. This approach may include building a precedence hierarchy of meta-constraints and assigning normalized weights to each. The system then collects estimated affinity and anti-affinity rules, which may include confidence weights. These rules are further refined based on the weights of the meta-constraints, thereby amplifying or attenuating the weights of these rules. Based on these refined rules, the system may identify various possible scenarios of part placement that would satisfy these rules. The system may then solve a constraint satisfaction problem to determine the final placement of the parts.

[0056] A final exemplary approach is an iterative user-guided analysis, also known as what-if analysis. In this approach, a user or administrator is presented with an initial set of rules and the resulting partial placement. The user can then provide feedback or input identifying changes to the priority of one or more of the rules. If the priority of the rules is changed, the placement of the parts may be changed. In response, the system re-runs the placement analysis based on the user feedback and presents this new partial placement to the user. The user can then provide additional input or feedback that changes the priority of the rules, which causes the system to re-run the analysis and generate a new partial placement. This process can be performed iteratively until the user is satisfied with the placement of the parts in the remote service environment. Once the user confirms the partial placement, the confirmed placement can be implemented.

[0057] Once affinity and anti-affinity rules and pod designs are established, the system can place parts of the application in the service environment according to the rules. In other words, once affinity and anti-affinity rules are established, the system can deploy the application in the service environment by placing parts in the environment according to the rules. Furthermore, the parts can be placed in the clusters or pods of the service environment according to the pod design.

[0058] FIG. 4 illustrates an overall system architecture of the described system and method. An application specification 401 is received at the system. From the application specification, the system identifies partial information 402, for example, by determining service interactions, discovering service relationships, discovering service dependencies, extracting placement constraints, discovering common storage, extracting fault tolerance requirements, and any other information. From the partial information, the system can extract affinity and anti-affinity indicators 403A and pod design indicators 403B. The affinity and anti-affinity indicators 403A can include both hard and soft indicators that specify whether the indicator is a requirement or a preference, respectively. The extracted affinity and anti-affinity indicators 403A can be combined to construct affinity and anti-affinity rules 404A. The pod design indicators can be combined to identify a pod design that indicates which containers should be placed together in a pod of a container-based environment 404B.

[0059] As shown in FIG. 5, the computer system / server 12' in the cloud computing node 10' is shown in the form of a general-purpose computing device. The components of the computer system / server 12' may include, but are not limited to, at least one processor or processing unit 16', a system memory 28', and a bus 18' coupling various system components, including the system memory 28', to the processor 16'. The bus 18' represents at least one of any of several types of bus structures, including a memory bus or memory controller, a peripheral bus, an accelerated graphics port, and a processor or local bus using any of a variety of bus architectures. By way of example and not limitation, such architectures include an Industry Standard Architecture (ISA) bus, a Micro Channel Architecture (MCA) bus, an Enhanced ISA (EISA) bus, a Video Electronics Standards Association (VESA) local bus, and a Peripheral Component Interconnect (PCI) bus.

[0060] The computer system / server 12' typically includes a variety of computer system readable media. Such media may be any available media that is accessible by the computer system / server 12' and includes both volatile and nonvolatile media, removable and non-removable media.

[0061] The system memory 28' may include computer system readable media in the form of volatile memory, such as random access memory (RAM) 30' and / or cache memory 32'. The computer system / server 12' may further include other removable / non-removable volatile / non-volatile computer system storage media. By way of example only, a storage system 34' may be provided for reading from and writing to a non-removable, non-volatile magnetic medium (not shown, typically referred to as a "hard drive"). Although not shown, a magnetic disk drive may be provided for reading from and writing to a removable, non-volatile magnetic disk (e.g., a "floppy disk"), and an optical disk drive may be provided for reading from and writing to a removable, non-volatile optical disk, such as a CD-ROM, DVD-ROM, or other optical medium. In such an example, each may be connected to the bus 18' by at least one data media interface. As further illustrated and described below, the memory 28' may include at least one program product having a set (e.g., at least one) of program modules configured to perform the functions of an embodiment of the present invention.

[0062] A program / utility 40' having a set (at least one) of program modules 42' may be stored in memory 28', as well as (by way of example and not limitation) an operating system, at least one application program, other program modules, and program data. Each of the operating system, at least one application program, other program modules, and program data, or any combination thereof, may comprise an implementation of a networking environment. The program modules 42' generally perform the functions and / or methodologies of embodiments of the invention described herein.

[0063] The computer system / server 12' may also communicate with at least one external device 14', such as a keyboard, pointing device, display 24', at least one device that allows a user to interact with the computer system / server 12', or any device that allows the computer system / server 12' to communicate with at least one other computing device (e.g., a network card, modem, etc.), or combinations thereof. Such communication may occur via an input / output (I / O) interface 22'. Still further, the computer system / server 12' may communicate with at least one network, such as a local area network (LAN), a general wide area network (WAN), or a public network (e.g., the Internet), or combinations thereof, via a network adapter 20'. As shown, the network adapter 20' communicates with other components of the computer system / server 12' via a bus 18'. It is understood that other hardware and / or software components, not shown, may be used with the computer system / server 12'. Examples include, but are not limited to, microcode, device drivers, redundant processing units, external disk drive arrays, RAID systems, tape drives, and data archive storage systems.

[0064] This disclosure has been presented for purposes of illustration and description, but is not intended to be exhaustive or limiting. Many modifications and variations will be apparent to those skilled in the art. The embodiments have been chosen and described in order to explain the principles and practical applications and to enable others skilled in the art to understand the disclosure.

[0065] Although illustrative embodiments of the present invention have been described herein with reference to the accompanying drawings, it is to be understood that embodiments of the present invention are not limited to those precise embodiments, and various other changes and modifications can be made by those skilled in the art without departing from the scope or spirit of the present disclosure.

[0066] The present invention may be a system, a method, or a computer program product, or a combination thereof. The computer program product may include a computer-readable storage medium (or media) having computer-readable program instructions thereon for causing a processor to carry out aspects of the present invention.

[0067] A computer readable storage medium may be any tangible device capable of holding and storing instructions for use by an instruction execution device. A computer readable storage medium may be, for example, but not limited to, an electronic storage device, a magnetic storage device, an optical storage device, an electromagnetic storage device, a semiconductor storage device, or any suitable combination thereof. A non-exhaustive list of more specific examples of computer readable storage media includes portable computer diskettes, hard disks, random access memory (RAM), read only memory (ROM), erasable programmable read only memory (EPROM or flash memory), static random access memory (SRAM), portable compact disk read only memory (CD-ROM), digital versatile disk (DVD), memory stick, floppy disk, mechanically encoded devices such as punch cards or groove ridge structures having instructions recorded thereon, and any suitable combination thereof. A computer-readable storage medium, as used herein, should not be construed to be a transitory signal per se, such as, for example, radio waves or other freely propagating electromagnetic waves, electromagnetic waves propagating through a waveguide or other transmission medium (e.g., light pulses passing through a fiber optic cable), or electrical signals transmitted over a wire.

[0068] The computer readable program instructions described herein may be downloaded from a computer readable storage medium to the respective computing / processing device or to an external computer or storage device over a network, such as, for example, the Internet, a local area network, a wide area network, or a wireless network, or a combination thereof. The network may include copper transmission cables, optical transmission fiber, wireless transmission, routers, firewalls, switches, gateway computers, or edge servers, or a combination thereof. A network adapter card or network interface of each computing / processing device receives the computer readable program instructions from the network and transfers the computer readable program instructions for storage in a computer readable storage medium within the respective computing / processing device.

[0069] The computer readable program instructions for carrying out the operations of the present invention may be source or object code written in any combination of one or more programming languages, including assembler instructions, instruction set architecture (ISA) instructions, machine instructions, machine dependent instructions, microcode, firmware instructions, state setting data, or object oriented programming languages ​​such as Smalltalk, C++, and traditional procedural programming languages ​​such as the "C" programming language or similar programming languages. The computer readable program instructions may be executed entirely on the user's computer, partially on the user's computer, as a standalone software package, partially on the user's computer and partially on a remote computer, or entirely on a remote computer or server. In the last scenario, the remote computer may be connected to the user's computer via any type of network, including a local area network (LAN) or wide area network (WAN), or a connection may be made to an external computer (e.g., via the Internet using an Internet Service Provider). In some embodiments, electronic circuitry including, for example, a programmable logic circuit, a field programmable gate array (FPGA), or a programmable logic array (PLA) may execute computer readable program instructions by utilizing state information of the computer readable program instructions to personalize the electronic circuitry to perform aspects of the invention.

[0070] Aspects of the present invention are described herein with reference to flowchart illustrations and / or block diagrams of methods, apparatus (systems), and computer program products according to embodiments of the invention. It will be understood that each block of the flowchart illustrations and / or block diagrams, and combinations of blocks in the flowchart illustrations and / or block diagrams, can be implemented by computer-readable program instructions. These computer-readable program instructions can be provided to a processor of a general purpose computer, special purpose computer, or other programmable data processing apparatus to generate a machine such that, when the instructions are executed via the processor of the computer or other programmable data processing apparatus, means are generated for implementing the functions / acts specified in one or more blocks of the flowchart illustrations and / or block diagrams. These computer-readable program instructions can also be stored on a computer-readable storage medium capable of directing a computer, programmable data processing apparatus, or other device, or combination thereof, to function in a particular manner, such that the computer-readable storage medium on which the instructions are stored constitutes an article of manufacture including instructions that implement aspects of the functions / acts specified in one or more blocks of the flowchart illustrations and / or block diagrams.

[0071] Furthermore, computer-readable program instructions may be loaded into a computer, other programmable data processing apparatus, or other device and caused to perform a series of operational steps on the computer, other programmable apparatus, or other device to generate a computer-implemented process that, when executed on the computer, other programmable apparatus, or other device, implements the functions / acts specified in one or more blocks of the flowcharts and / or block diagrams.

[0072] The flowcharts and block diagrams in the figures illustrate the architecture, functionality, and operation of possible implementations of systems, methods, and computer program products according to various embodiments of the present invention. In this regard, each block in the flowcharts or block diagrams may represent a module, segment, or portion of instructions that includes one or more executable instructions for implementing the specified logical function. In some alternative implementations, the functions described in the blocks may occur out of the order shown. For example, depending on the functionality involved, two blocks shown in succession may in fact be executed substantially simultaneously, or the blocks may possibly be executed in the reverse order. It will also be noted that each block of the block diagrams and / or flowchart illustrations, and combinations of blocks in the block diagrams and / or flowchart illustrations, may be implemented by a dedicated hardware-based system that performs the specified functions or acts or executes a combination of dedicated hardware and computer instructions.

Claims

1. A computer-implemented method executed by a computer system, the computer system comprising: receiving an application to be deployed in a container-based environment, the application being divided into containers containing portions of the application; obtaining a specification of the application that includes information regarding portions of the application that are contained within a given container; extracting from said specification partial information corresponding to relationships and interferences between different parts of said application; identifying affinity indicators and anti-affinity indicators for the portions of the application from the portion information, the affinity indicators being based on the associations between different portions of the application and the anti-affinity indicators being based on the interferences between different portions of the application; constructing affinity and anti-affinity rules for the container by combining the affinity indicators to construct affinity rules and combining the anti-affinity indicators to construct anti-affinity rules, where the affinity rules identify containers that are hosted by the same host in the container-based environment and the anti-affinity rules identify containers that are hosted by different hosts in the container-based environment; 4. A computer-implemented method comprising:

2. The computer-implemented method of claim 1 , further comprising identifying from the portion information a pod design indicator that indicates a portion of the application that is contained within a pod of the container-based environment.

3. The computer-implemented method of claim 2 , further comprising utilizing the pod design indicators to build a pod design for the application within the container-based environment.

4. The computer-implemented method of any one of claims 1 to 3, wherein the combining of the affinity indicators and the combining of the anti-affinity indicators comprises utilizing a rules-based technique.

5. 5. The computer-implemented method of claim 1, wherein the combining of the affinity indicators and the combining of the non-affinity indicators comprises obtaining from a user precedence constraints that identify affinity and non-affinity indicators that are to be given greater weight than other affinity and non-affinity indicators, and incorporating the precedence constraints into constructing the affinity and non-affinity rules.

6. 6. The computer-implemented method of claim 1, wherein the combining of the affinity indicators and the combining of the non-affinity indicators comprises performing an iterative user-guided analysis, the iterative user-guided analysis comprising iteratively (i) presenting the affinity rules and anti-affinity rules to a user, (ii) receiving input from a user that changes a priority of at least one of the affinity rules and the non-affinity rules, and (iii) modifying the affinity rules and anti-affinity rules based on the input from the user.

7. The computer-implemented method of any one of claims 1 to 6, wherein identifying affinity indicators comprises identifying interactions between application parts from service interactions and network configurations.

8. 8. The computer-implemented method of claim 1, wherein the identifying an affinity indicator and the identifying a non-affinity indicator comprise identifying resource requirements of the application portions that indicate one of: no resource interference between the application portions and there is resource interference between the application portions.

9. 9. The computer-implemented method of claim 1, wherein identifying an anti-affinity indicator comprises identifying a number of instances of a given portion that are deployed to the container-based environment, and identifying fault tolerance requirements across the number of instances.

10. The computer-implemented method of any one of claims 1 to 9, wherein the portion information includes interactions between application portions, relationships between application portions, constraints of application portions, and fault tolerance requirements.

11. A computer program for causing a computer system to execute the computer-implemented method according to any one of claims 1 to 10.

12. A computer-readable recording medium having the computer program according to claim 11 recorded thereon.

13. An apparatus comprising a computer-readable storage medium having computer-readable program code embodied thereon, comprising: The computer readable program code includes code for receiving an application to be deployed in a container-based environment, the application being divided into containers containing portions of the application; the computer readable program code includes code for obtaining a specification of the application that includes information regarding portions of the application that are included within a given container; the computer readable program code includes code for extracting, from the specification, portion information corresponding to associations and interferences between different portions of the application; the computer readable program code includes code for identifying from the portion information affinity indicators and anti-affinity indicators for the portions of the application, the affinity indicators being based on the associations between different portions of the application and the anti-affinity indicators being based on the interferences between different portions of the application; the computer readable program code includes code for constructing affinity and anti-affinity rules for the container by combining the affinity indicators to construct affinity rules and combining the anti-affinity indicators to construct anti-affinity rules, the affinity rules identifying containers that are hosted by the same host in the container-based environment and the anti-affinity rules identifying containers that are hosted by different hosts in the container-based environment; Device.

Images