Risk-based scheduling of containerized application services
By introducing a scheduler extender and leveraging IT sensor information to optimize Kubernetes scheduling decisions, the problem of Kubernetes' inability to effectively reduce IT operational risks is solved, enabling more reliable containerized application deployment.
Patent Information
- Application Number
- CN202080051399.X
- Authority / Receiving Office
- CN · China
- Patent Type
- Patents(China)
- Current Assignee / Owner
- Priority Date
- 2019-07-15
- Filing Date
- 2020-07-15
- Publication Date
- 2026-01-09
- Estimated Expiration
- 2040-07-15
AI Technical Summary
The Kubernetes scheduling system cannot effectively reduce the risk of IT operational problems. It fails to consider the status, health, or operational status of the physical infrastructure on which the nodes reside, which may lead to the risk that applications may crash or need to be relocated due to critical infrastructure failures.
A scheduler extender is introduced to receive IT sensor information, filter the node list, filter or prioritize nodes based on IT operation health scores, and consider power capacity, phase imbalance, thermal capacity, etc., to optimize the deployment decisions of containerized applications.
By taking into account the state of the physical infrastructure, the risk of application crashes due to critical infrastructure failures is reduced, improving the reliability and efficiency of containerized application deployment.
Smart Images

Figure CN114127757B_ABST
Abstract
Description
[0001] Cross Reference to Related Applications
[0002] This application claims priority to provisional patent application serial no. 62 / 874,272, filed July 15, 2019. The entire contents of U.S. provisional patent application serial no. 62 / 874,272, filed July 15, 2019, are incorporated herein by reference. TECHNICAL FIELD
[0003] The present disclosure relates generally to the field of dispatching application services, and more particularly to a risk-based dispatching application service. BACKGROUND
[0004] Kubernetes is an open source system for automating the deployment, scaling, and management of containerized applications. Programs running on Kubernetes are packaged into containers, which are independent execution environments. Any program and all of its dependencies can be packaged into a single file and then shared. Containers are becoming the preferred choice for deploying and managing software applications. Kubernetes wraps one or more containers into a higher level structure (e.g., a Pod) that is housed on a node. A node is the smallest unit of computing hardware and represents a single machine, which can be a physical machine (e.g., a server) or a virtual machine (VM). A Kubernetes cluster is a pool of nodes, which can include a master Kubernetes node configured to manage a plurality of Kubernetes worker nodes. When a Pod (e.g., a program / application) is deployed onto a Kubernetes cluster, the cluster intelligently handles distributing the Pod. The cluster is made up of different numbers of nodes (e.g., physical servers) housed in racks in a data center. These physical servers can be housed in a single rack or distributed across several racks. These racks can be powered by the same power source or different power sources. In a redundant setup, a rack will be powered by two different power sources. In the same vein, a rack can be cooled by the same computer room air conditioning (CRAC) unit or computer room air handler (CRAH).
[0005] Currently, Kubernetes deploys Pods (e.g., applications) to nodes based on only computing unit processor (CPU) resources and memory (e.g., random access memory (RAM)) resources. As a result, Kubernetes is unable to effectively reduce the risk of information technology (IT) operational issues. Therefore, it would be advantageous to provide a system to remedy the shortcomings of the aforementioned traditional approach. SUMMARY
[0006] Accordingly, the present disclosure is directed to a system for risk-based scheduling of containerized application services. The system can include a scheduler extender configured to receive a list of nodes available to process an application or a portion of an application to be completed by one or more nodes in the list of nodes and receive information from one or more information technology (IT) sensors configured to measure aspects of IT operations associated with the nodes in the list of nodes. The scheduler extender can be configured to filter the list of nodes based on the information from the one or more information technology (IT) sensors measuring aspects of IT operations associated with the nodes of the list of nodes.
[0007] It is to be understood that both the foregoing general description and the following detailed description are exemplary and explanatory only and are not necessarily restrictive of the present disclosure. The accompanying drawings below Figure One serve to explain the principles of the present disclosure. BRIEF DESCRIPTION OF DRAWINGS
[0008] The numerous advantages of the present disclosure can be better understood by referring to the drawings in which:
[0009] Figure 1 depicts an exemplary system including a scheduler extender for risk-based scheduling of containerized application services in accordance with embodiments of the present disclosure;
[0010] Figure 2 depicts exemplary filtering of a list of nodes by a scheduler extender based on information from IT sensors in accordance with embodiments of the present disclosure;
[0011] Figure 3 depicts an exemplary system for risk-based scheduling of containerized application services including topology services and discovery services in accordance with embodiments of the present disclosure;
[0012] Figure 4 depicts an exemplary diagram including a scheduler extender receiving historical IT information and data from IT sensors in accordance with embodiments of the present disclosure; and
[0013] Figure 5 depicts an exemplary flowchart of a method for risk-based scheduling of containerized application services in accordance with embodiments of the present disclosure. DETAILED DESCRIPTION
[0014] Reference will now be made in detail to the disclosed subject matter.
[0015] Before explaining any embodiments of this disclosure in detail, it should be understood that the embodiments are not limited in application based on the details of the structure or function set forth in the following description or shown in the accompanying drawings. Different embodiments can be practiced or implemented in various ways. Moreover, it should be understood that the wording and terminology used herein are for descriptive purposes and should not be considered limiting. The use of terms such as “comprising,” “including,” or “having,” and variations thereof herein generally means including the items listed thereafter and their equivalents, as well as additional items. Furthermore, unless otherwise stated, technical terms may be used in accordance with conventional usage. It is also contemplated that similar reference numerals may describe similar components and their equivalents.
[0016] This disclosure relates to a system for risk-based scheduling of containerized application services. The system may include a scheduler extender configured to receive a list of nodes that can be used to process an application or part of an application to be performed by one or more nodes in the node list, and to receive information from one or more information technology (IT) sensors configured to measure aspects of IT operations associated with the nodes in the node list. The scheduler extender may be configured to filter the node list based on information from the one or more IT sensors that measure aspects of IT operations associated with the nodes in the node list.
[0017] It is conceivable that containerized application services may include Kubernetes systems, VMware systems, etc., but the specification provides an exemplary system for operating Kubernetes systems.
[0018] Current scheduling systems define physical nodes that have very limited or no knowledge of the underlying IT physical infrastructure resources supporting the applications. Systems such as VMware and Kubernetes define nodes based on processing power, memory capacity, and affinity rules. However, these systems do not consider the state, health, or operational status of the physical infrastructure on which the node resides.
[0019] Containers are becoming the new standard for deploying and managing software. Container orchestration software / platforms, such as Kubernetes, automate application deployment, scaling, and management of operations of application containers across a cluster of hosts (e.g., servers). Kubernetes takes into account individual and collective resource requirements, quality of service requirements, hardware / software / policy constraints, affinity and anti-affinity specifications, data locality, workload inference across workloads, deadlines, and the like. However, the individual and collective resource requirements used in Kubernetes are based only on processing power and memory capacity, such as computer processing unit (CPU) resources and memory (e.g., RAM) resources. Kubernetes does not take into account available power, power redundancy, or thermal conditions of servers or air around a server rack when making scheduling decisions. Thus, Kubernetes lacks awareness of the state of critical information technology infrastructure and physical locations. Physical locations can include, but are not limited to: where a server is physically installed, in which rack, and where in the data center the rack is physically located; what power source is serving the rack via the rack PDU (rPDU), what power outlet on the rPDU the server is plugged into; what cooling equipment is cooling and extracting heat, and what sensors are measuring the temperature of each server or rack; and which racks and servers will be affected by a failure of a downstream uninterruptable power supply (UPS) or computer room air conditioning (CRAC) unit or by taking that device out of service for maintenance or repair.
[0020] The state of critical infrastructure and physical locations is important for enhancing decisions about scheduling in order to reduce the risk of programs and applications crashing or having to be relocated due to imminent or potential critical infrastructure problems. Critical infrastructure failures can occur at any time due to equipment failure or human error, and Kubernetes is not able to effectively or efficiently reduce the risk of such failures occurring. Thus, it would be advantageous to provide a system to remedy the shortcomings of the traditional approaches described above.
[0021] Reference is made to Figure 1 FIG. 1 illustrates an exemplary system including a scheduler extender for risk-based scheduling of containerized application services, in accordance with embodiments of the present disclosure. The system of the present disclosure can include a virtual cluster of containerized application services (e.g., a Kubernetes cluster). The virtual cluster can include a plurality of nodes, where the plurality of nodes includes a plurality of pods. The plurality of pods can be configured to support or complete a function.
[0022] Each of the plurality of nodes is assigned to the virtual cluster. When an application or a portion of an application (e.g., a Pod) needs to be deployed, the application is placed in a scheduling queue. The application or the portion of the application can be deployed to a node of the plurality of nodes after the virtual cluster determines, based on logical data from one or more workload metrics, which node the application should be located on. The one or more workload metrics can be based on processing power and memory capacity, such as central processing units (CPUs), memory (e.g., RAM), etc. The scheduler extender can include a processing device and a storage device, the processing device configured to execute computer-readable instructions stored on the storage device that, when executed by the processing device, cause the processing device to perform operations to filter nodes for executing an application or a portion of an application (e.g., a Pod) based on information from one or more information technology (IT) sensors that measure aspects of IT operations associated with the nodes.
[0023] The system can also include a physical infrastructure (e.g., a physical cluster). The physical infrastructure can include one or more computers or servers communicatively coupled to each other such that each computer or server of the one or more computers / servers can work together. The physical infrastructure can also include one or more server racks. The one or more server racks can include one or more servers.
[0024] The system can also include one or more pieces of upstream equipment. The one or more pieces of upstream equipment can include any hardware related to the physical infrastructure including, but not limited to, one or more power distribution units (PDUs) configured to provide power to the physical infrastructure, one or more computer room air conditioning (CRAC) units, one or more fans, etc.
[0025] The physical infrastructure can also include one or more IT sensors configured to measure one or more aspects of information technology (IT) operations, such as IT operation metrics. It is contemplated that the one or more IT sensors can be hardware-based sensors attached to the physical infrastructure. Further, it is contemplated that the one or more IT sensors can be integrated on an on-board sensor or meter configured to communicate with a data center infrastructure management (DCIM) system. The one or more IT sensors can be associated with each node or server of the system.
[0026] The one or more IT sensors can be configured to generate data based on IT operational metrics, such as at least one of power capacity, phase imbalance, power redundancy, thermal capacity, and the like. The one or more IT sensors can include any sensor known in the art suitable for generating at least one of power capacity, phase imbalance, power redundancy, thermal capacity, and the like. For example, the one or more IT sensors can include one or more thermal sensors for generating temperature data of the physical infrastructure. As another example, the one or more IT sensors can include a current measuring device. As another example, the one or more IT sensors can include a phase detection device. As another example, the one or more IT sensors can include a power measuring device. As another example, the one or more IT sensors can include one or more pressure sensors. As an additional example, the one or more IT sensors can include an air flow meter.
[0027] The system can also include a data center infrastructure management (DCIM) system. The DCIM system can collate, store, and analyze data related to power and cooling of the data center in real-time. The DCIM software, such as an application programming interface (API), can aggregate and analyze data from the IT sensors and can also provide a display of current status information and can provide alerts. The DCIM software can be executed by a computing device, and the DCIM software can be a networked computing device that can allow for transmission of data to a cloud-based server device. One example of a DCIM system and API is the Trellis® TM Platform, available from the assignee of the present disclosure. The Trellis® TM Platform is configured to receive data from the one or more IT sensors or directly from the power and cooling devices (e.g., one or more pieces of upstream equipment), as Figure 3 shown. The DCIM system can be configured to store the data in memory on the DCIM system. The DCIM system can also be configured to communicate such data measured by the one or more IT sensors to one or more components of the system (e.g., a scheduler extender, such as a scheduler extender in a Kubernetes cluster). The DCIM system can also be configured to convert the data (e.g., data from the one or more IT sensors) into a format suitable for the scheduler extender.
[0028] Referring to Figure 2FIG. 2, shows exemplary filtering of a list of nodes by a scheduler extender based on information from IT sensors, according to embodiments of the present disclosure. It is contemplated that the list of nodes can be presented first by a containerized application service (Kubernetes or VMware) where the list of nodes includes nodes with sufficient processing power and sufficient memory capacity. The scheduler extender can be configured to filter the list of nodes identified in the dispatch queue based on data from one or more IT sensors (through a virtual cluster). The scheduler extender can be configured to remove one or more nodes from the list of nodes based on data from one or more IT sensors (e.g., as shown in FIG. 2 by removing node 2 and node 5 in an exemplary manner). Alternatively, the scheduler extender can be configured to prioritize the list of nodes identified in the dispatch queue based on maintenance information of one or more upstream devices. For example, the scheduler extender can be configured to take specific units offline and out of service based on maintenance information of one or more upstream devices. Figure 2
[0029] The system can be configured to generate an information technology (IT) operational health score based on data from one or more IT sensors coupled to or associated with one or more components of a physical infrastructure. The system can also be configured to generate the IT operational health score based on data directly from a DCIM system. The IT operational health score can be based on at least one of power capacity, phase imbalance, power redundancy, thermal capacity, etc. The IT operational health score can also be based on one or more space management components including, but not limited to, asset management, twist capacity, site planning, etc. The IT operational health score can be generated using any algorithm suitable for analyzing at least one of power capacity, phase imbalance, power redundancy, thermal capacity, space management, etc.
[0030] The scheduler extender can be configured to filter the list of nodes (e.g., remove nodes from the list of nodes in the dispatch queue) using the IT operations health score generated based on data from one or more IT sensors. For example, at least one node in the list of nodes can be removed (e.g., filtered) from the queue due to a server of the physical infrastructure being too hot. As another example, at least one node of a plurality of nodes can be removed from the queue due to a server of the physical infrastructure not having sufficient power capacity. As another example, at least one node of a plurality of nodes can be removed from the queue due to a server of the physical infrastructure not having sufficient power and cooling capacity. By way of further example, at least one node of a plurality of nodes can be removed from the queue in order to prevent phase imbalance in a server of the physical infrastructure. As another example, at least one node of a plurality of nodes can be removed from the queue due to a lack of sufficient power redundancy.
[0031] The scheduler extender can also be configured to prioritize the plurality of nodes based on the IT operations health score. For example, as shown in Figure 2 , the scheduler extender can be configured to prioritize the plurality of nodes such that a best fit node in the dispatch queue is higher than a least fit node in the dispatch queue. For example, prior to deploying an application to the least fit node in the queue (e.g., node 1 shown in Figure 2 exemplary manner), the system can deploy the application to a higher best fit node in the queue (e.g., node 4 shown in Figure 2 exemplary manner). It is contemplated that the best fit node can have the highest IT operations health score, where the least fit node can have the lowest IT operations health score.
[0032] Referring to Figure 3 , an exemplary system for risk-based scheduling of containerized application services including a topology service and a discovery service according to embodiments of the present disclosure is shown. The system for risk-based scheduling of containerized application services can include a discovery service configured to identify a plurality of nodes (e.g., physical servers). For example, the discovery service can discover the plurality of nodes (e.g., physical servers) by sending a signal to each of the plurality of nodes. The discovery service can also be configured to extract from each of the plurality of nodes (e.g., physical servers) specific data that uniquely identifies each node (e.g., each physical server), such as a system ID, a machine ID, a MAC address, an IP address, a hostname, and / or a serial number.
[0033] The system for risk-based scheduling of containerized application services can also include a topology service configured to discover at least one of a plurality of nodes, associated Pods, and associated containers running on a virtual cluster. For example, the topology service can discover at least one of a plurality of nodes, associated Pods, or associated containers using an algorithm that automatically maps logical representations of individual nodes (e.g., associated Pods and containers) to individual physical servers, as well as discover the location and positioning of servers within a server rack, and even discover all associated power feeds (e.g., UPS, PDU, etc.) and cooling systems. For example, the system can identify that node 2 is located on server 4, which is located in rack 2. Such a topology service allows the system to efficiently and accurately remove and / or prioritize nodes so that the system can deploy applications (e.g., Pods) to the correct nodes.
[0034] The system for risk-based scheduling of containerized application services can also include a topology user interface (UI) configured to allow a user to edit (e.g., change, delete, update, etc.) topology service data. For example, a user can edit topology service data to remove a server that is undergoing repairs or experiencing a failure. As another example, a user can edit the connectivity of equipment (e.g., what servers are mapped to what nodes).
[0035] The system for risk-based scheduling of containerized application services can also be configured to deploy an application to each of the plurality of nodes based on one or more workload metrics (from the virtual cluster) and an IT operations health score and / or data from one or more IT sensors. The one or more IT sensors can be associated with a DCIM system. DCIM software can aggregate and analyze data from IT sensors and can also provide a display of current status information and can provide alerts. The DCIM software can be executed by a computing device, and the DCIM software can be a networked computing device that can allow data to be transmitted to a cloud-based server device. One example of a DCIM system and API is the Trellis® TM Platform, available from the assignee of the present disclosure. The Trellis® TM Platform is configured to receive data from one or more IT sensors or directly from power and cooling devices (e.g., one or more upstream devices).
[0036] A system for risk-based scheduling of containerized application services can be configured to manage deployment of applications to servers of a physical infrastructure based on an IT operations health score. For example, the system can be configured to deploy an application to a server of a physical infrastructure when the IT operations health score indicates that the server has sufficient power capacity or thermal capacity, reduced likelihood of phase imbalance, and sufficient power redundancy, among other examples. As another example, the system can be configured to stop deploying an application to a server of a physical infrastructure when the IT operations health score indicates that the server has substantially insufficient power capacity or insufficient thermal capacity, increased likelihood of phase imbalance and insufficient power redundancy, among other examples.
[0037] Referring to Figure 4 FIG. 1 illustrates an exemplary diagram of a scheduler extender that includes historical IT information and data from IT sensors, in accordance with embodiments of the present disclosure. The IT sensors can include thermal sensors, current measuring devices, power measuring devices, phase detection devices, pressure sensors, or air flow meters. Further, it is contemplated that the IT sensors can include humidity sensors, dew point sensors, vibration sensors, smoke detectors, or contact sensors. The contact sensors can provide an alert if the facility has been improperly breached. The system can be configured to store the historical IT information on a memory device or storage device. The scheduler extender of the system can be configured to receive the historical IT information and utilize such information in the IT operations health score in conjunction with data received from one or more IT sensors. The historical IT information can include, but is not limited to, time of day, future predictions, among other examples.
[0038] It is contemplated that the system can have many advantages. For example, the system can reduce risk by deciding which node a given application should be deployed to (e.g., a node that has sufficient power and thermal capacity and matches the redundancy strategy of the application). For example, the system can reduce risk by deploying an application to a node after generating an IT operations health score and such score indicates that the physical infrastructure has sufficient capacity to handle the application. As another example, the system can reduce the risk of an IT device outage that is running a business application. For example, by deploying an application to a node after collecting an IT operations health score, the risk of a physical infrastructure failure is reduced.
[0039] Further, it is contemplated that the IT operational health score indicates an overall health and capacity of the IT system (e.g., physical infrastructure) supporting the server by taking into account at least one of power capacity, phase imbalance, power redundancy, thermal capacity, etc. Each server can have a unique IT operational health score based on at least one of power capacity, phase imbalance, power redundancy, thermal capacity, etc. of that particular server. The system would not deploy an application to a node (e.g., server) that has an IT operational health score that reflects low power capacity or low thermal capacity. Further, the system would not deploy an application to a node (e.g., server) that has an IT operational health score that indicates a phase imbalance or a likelihood of lack of power redundancy.
[0040] Referring to Figure 5 , an example flowchart of a method 500 for risk-based scheduling of containerized application services according to embodiments of the present disclosure is shown. The method 500 can be performed by a system for risk-based scheduling of containerized application services as shown in Figure 1 and Figure 3 . The method 500 for risk-based scheduling of containerized application services can include receiving a list of nodes based on containerized application services, where the list of nodes includes nodes with sufficient processing power and memory capacity 510. Each node in the list of nodes can refer to a physical server in a particular rack. The method 500 can further include receiving information from one or more information technology (IT) sensors configured to measure aspects of IT operations associated with the nodes of the list of nodes 520. The method 500 can further include filtering the list of nodes based on the information from the one or more information technology (IT) sensors 530.
[0041] It is contemplated that filtering the list of nodes based on the information from the one or more information technology (IT) sensors 530 can include removing at least one node from the list of nodes 535. Additionally, it is contemplated that filtering the list of nodes based on the information from the one or more information technology (IT) sensors 530 can include prioritizing nodes from the list of nodes available to process an application or a portion of an application 537.
[0042] Those skilled in the art will recognize that the state of the art has progressed to the point where there is little distinction left between hardware and software implementations of aspects of systems; the use of hard-coded versus software processing will often depend upon the expected frequency of use and whether the functionality needs to be changed over time. Those skilled in the art will also recognize that the benefits of software-based implementations are not necessarily equally inherent in all types of computer
[0043] The foregoing detailed description has set forth various embodiments of the devices and / or processes via the use of block diagrams, flowcharts, and / or examples. Insofar as such block diagrams, flowcharts, and / or examples contain one or more functions and / or operations, it will be understood by those within the art that each function and / or operation within such block diagrams, flowcharts, and / or examples can be implemented, individually and / or collectively, by a wide range of hardware, software, firmware, or virtually any combination thereof. In one embodiment, several portions of the subject matter described herein can be implemented via Application Specific Integrated Circuits (ASICs), Field Programmable Gate Arrays (FPGAs), digital signal processors (DSPs), or other integrated formats. However, those skilled in the art will recognize the embodiments disclosed herein, in whole or in part, can be equivalently implemented in integrated circuits, as one or more computer programs running on one or more computers (e.g., as one or more programs running on one or more computer systems), as one or more programs running on one or more processors (e.g., as one or more programs running on one or more microprocessors), as firmware, or as virtually any combination thereof, and that designing the circuitry and / or writing the code for the software and or firmware would be well within the skill of one of skill in the art in light of this disclosure. In addition, those skilled in the art will appreciate that the mechanisms of the subject matter described herein are capable of being distributed as a program product in a variety of forms, and that an illustrative embodiment of the subject matter described herein applies regardless of the particular type of signal bearing media used to actually carry out this distribution. Examples of a signal bearing media include one or more of the following: a recordable type medium such as a floppy disk, a hard disk drive, a Compact Disc (CD), a Digital Video Disk (DVD), a digital tape, a computer memory, etc.; and transmission type media such as digital and / or an analog communication
[0044] In general, those skilled in the art will recognize that the various aspects described herein can be implemented in a wide range of hardware, software, firmware, or any combination thereof, and that the various aspects described herein can be viewed as being composed of various types of "circuitry." Accordingly, as used herein "circuitry" includes, but is not limited to, electrical circuitry having at least one discrete electrical circuit, electrical circuitry having at least one integrated circuit, electrical circuitry having at least one application specific integrated circuit, electrical circuitry forming a general purpose computing device configured by a computer program (e.g., a general purpose computer configured by a computer program that at least partially carries out processes and / or devices described herein, or a microprocessor configured by a computer program that at least partially carries out processes and / or devices described herein), electrical circuitry forming a memory device (e.g., forms of random access memory), and / or electrical circuitry forming a communications device (e.g., a modem, a communications switch, or an optical-electrical equipment). Those skilled in the art will recognize that the subject matter described herein can be implemented in an analog or digital form, or a combination thereof, as can be suitable for an application.
[0045] Those skilled in the art will recognize that the herein described apparatus and / or process can be embodied as one or more computer-readable storage media (e.g., magnetic storage media such as a magnetic disk; optical storage media such as optical disks; volatile memory storage media such as DRAM, SRAM, and RAM; non-volatile memory storage media such as flash memory devices; and the like) having computer-readable program code embodied thereon that is executable by one or more computing devices to perform the operations described herein. Those skilled in the art will recognize that the computer-readable storage media can come in the form of a set of instructions readable by a machine, wherein the instructions are arranged to cause the machine to perform the operations described herein. Those skilled in the art will recognize that the computer-readable storage media can come in the form of a signal that is readable by a machine, wherein the signal is arranged to cause the machine to perform the operations described herein. Those skilled in the art will recognize that the computer-readable storage media can come in the form of a set of instructions readable by a machine, wherein the instructions are arranged to cause the machine to perform the operations described herein. Those skilled in the art will recognize that the computer-readable storage media can come in the form of a signal that is readable by a machine, wherein the signal is arranged to cause the machine to perform the operations described herein.
[0046] The subject matter described herein sometimes illustrates different components contained within, or connected with, different other components. It is to be understood that such depicted architectures are merely examples, and that in fact many other architectures can be implemented which achieve the same functionality. In a conceptual sense, any arrangement of components to achieve the same functionality is effectively "associated" such that the desired functionality is achieved. Hence, any two components herein combined to achieve a particular functionality can be seen as "associated with" each other such that the desired functionality is achieved, irrespective of architectures or intermediate components. Likewise, any two components so associated can also be viewed as being "operably connected", or "operably coupled", to each other to achieve the desired functionality, and any two components capable of being so associated can also be viewed as being "operably couplable" to each other to achieve the desired functionality. Specific examples of operably couplable include but are not limited to physically mateable and / or physically interacting components and / or wirelessly interactable and / or wirelessly interacting components and / or logically interacting and / or logically interactable components.
[0047] While particular aspects of the subject matter described in this specification have been shown and described, it will be apparent to those skilled in the art that, based upon the teachings herein, changes and modifications can be made in the subject matter described in this specification, to one of ordinary skill in the art nothing is considered sacrosanct. Therefore, the appended claims are to encompass all such changes and modifications as fall within the true spirit and scope of the subject matter described in this specification. Further, it should be understood that the application is defined by the appended claims.
Claims
1. A system for risk-based scheduling of containerized application services, comprising: a scheduler extender comprising a processing device and computer-readable instructions stored on a storage device that, when executed by the processing device, cause the processing device to perform operations comprising: receiving a list of nodes that can be used to process an application or a portion of an application to be completed by one or more nodes in the list of nodes; receiving information from one or more information technology (IT) sensors configured to measure aspects of IT operations associated with nodes in the list of nodes, the one or more IT sensors comprising thermal sensors, current measuring devices, power measuring devices, and phase detection devices; and filtering the list of nodes based on the information from the one or more IT sensors, wherein each node associated with the list of nodes refers to a physical server located in a particular rack, wherein filtering the list of nodes based on the information from the one or more IT sensors comprises prioritizing nodes from the list of nodes that can be used to process an application or a portion of an application based on an IT operations health score associated with each node computed from data from the one or more IT sensors, wherein the IT operations health score is an indication of the ability of each node to process the application or the portion of the application, and removing at least one node from the list of nodes that can be used to process an application or a portion of an application based on the information from the one or more IT sensors, wherein removing at least one node from the list of nodes that can be used to process an application or a portion of an application based on the information from the one or more IT sensors is based on an IT operations health score associated with each node computed from data from the one or more IT sensors, wherein the IT operations health score is lower when the associated node of the IT operations health score has insufficient power capacity or phase imbalance.
2. The system of claim 1, wherein, the application or portion of an application is a Pod.
3. The system of claim 1, wherein, receiving a list of nodes that can be used to process an application or a portion of an application to be completed by one or more nodes in the list of nodes is based on the containerized application services, wherein the list of nodes comprises nodes having sufficient processing power and memory capacity.
4. The system of claim 1, wherein, the one or more IT sensors comprise vibration sensors, humidity sensors, pressure sensors, or air flow meters.
5. The system of claim 1, wherein, the one or more IT sensors are associated with a data center infrastructure management (DCIM) system.
6. The system of claim 5, wherein, receiving information from the one or more IT sensors comprises receiving the information from the DCIM system.
7. The system of claim 1, wherein, the IT operations health score is higher when the associated node of the IT operations health score has sufficient power capacity or phase balance.
8. The system of claim 1, wherein, filtering the list of nodes is further based on historical data.
9. A system for risk-based scheduling of containerized application services, comprising: a scheduler extender comprising a processing device and computer readable instructions stored on a storage device that, when executed by the processing device, cause the processing device to perform operations comprising: receiving a list of nodes that can be used to process an application or a portion of an application to be completed by one or more nodes of the list of nodes, the list of nodes being based on the containerized application service, wherein the list of nodes comprises nodes having sufficient processing power and memory capacity; receiving information from one or more information technology (IT) sensors configured to measure aspects of IT operations associated with nodes in the list of nodes, the one or more IT sensors comprising thermal sensors, current measuring devices, power measuring devices, and phase detection devices; and filtering the list of nodes based on the information from the one or more IT sensors, wherein each node associated with the list of nodes refers to a physical server located in a particular rack, wherein filtering the list of nodes based on the information from the one or more IT sensors comprises prioritizing nodes from the list of nodes that can be used to process an application or a portion of an application based on an IT operations health score associated with each node computed from data from the one or more IT sensors, wherein the IT operations health score is an indication of each node’s ability to process the application or the portion of the application, and removing at least one node from the list of nodes that can be used to process an application or a portion of an application based on the information from the one or more IT sensors, wherein removing at least one node from the list of nodes that can be used to process an application or a portion of an application based on the information from the one or more IT sensors is based on an IT operations health score associated with each node computed from data from the one or more IT sensors, wherein the IT operations health score is lower when the associated node of the IT operations health score has insufficient power capacity or phase imbalance.
10. The system of claim 9, wherein, the IT operations health score is higher when the associated node of the IT operations health score has sufficient power capacity or phase balance.
11. A computer-implemented method for risk-based scheduling of a containerized application service, the computer-implemented method being executable by a processing device and computer readable instructions stored on a storage device that, when executed by the processing device, cause the processing device to perform operations comprising: receiving a list of nodes that can be used to process an application or a portion of an application to be completed by one or more nodes of the list of nodes, the list of nodes being based on the containerized application service, wherein the list of nodes comprises nodes having sufficient processing power and memory capacity; receiving information from one or more information technology (IT) sensors configured to measure aspects of IT operations associated with nodes in the list of nodes, the one or more IT sensors comprising thermal sensors, current measuring devices, power measuring devices, and phase detection devices; and filtering the list of nodes based on the information from the one or more IT sensors, wherein each node associated with the list of nodes refers to a physical server located in a particular rack, wherein filtering the list of nodes based on the information from the one or more IT sensors comprises prioritizing nodes from the list of nodes that can be used to process an application or a portion of an application based on an IT operations health score associated with each node computed from data from the one or more IT sensors, wherein the IT operations health score is an indication of each node’s ability to process the application or the portion of the application, and removing at least one node from the list of nodes that can be used to process an application or a portion of an application based on the information from the one or more IT sensors, wherein removing at least one node from the list of nodes that can be used to process an application or a portion of an application based on the information from the one or more IT sensors is based on an IT operations health score associated with each node computed from data from the one or more IT sensors, wherein the IT operations health score is lower when the associated node of the IT operations health score has insufficient power capacity or phase imbalance. the IT operations health score is higher when the associated node of the IT operations health score has sufficient power capacity or phase balance. receiving information from one or more information technology (IT) sensors configured to measure aspects of IT operations associated with nodes in the list of nodes, the one or more IT sensors including thermal sensors, current measuring devices, power measuring devices, and phase detection devices; and filtering the list of nodes based on the information from the one or more IT sensors, wherein each node associated with the list of nodes refers to a physical server located in a particular rack, wherein filtering the list of nodes based on the information from the one or more IT sensors includes prioritizing nodes from the list of nodes that are capable of processing an application or a portion of an application based on an IT operations health score associated with each node that is computed from data from the one or more IT sensors, wherein the IT operations health score is an indication of the ability of each node to process the application or the portion of the application, and removing at least one node from the list of nodes that are capable of processing an application or a portion of an application based on the information from the one or more IT sensors, wherein removing at least one node from the list of nodes that are capable of processing an application or a portion of an application based on the information from the one or more IT sensors is based on an IT operations health score associated with each node that is computed from data from the one or more IT sensors, wherein the IT operations health score is lower when the associated node of the IT operations health score has insufficient power capacity or phase imbalance.
12. The computer-implemented method of claim 11, wherein, wherein the IT operations health score is higher when the associated node of the IT operations health score has sufficient power capacity or phase balance.
Citation Information
Patent Citations
Autonomous distributed workload and infrastructure scheduling
US20170264493A1
Affinity based hierarchical container scheduling
US20180203736A1