Patent Publication Number: US-2021173716-A1

Title: Infrastructure resource mapping mechanism

Description:
BACKGROUND 
     A cloud service may refer to a service that includes infrastructure resources (a compute resource, a storage resource, a networking resource, etc.) connected with each other and/or platforms. Such infrastructure resources can collectively be referred to as “cloud resources.” A host (also referred to as a cloud service provider) may, as example, provide Software as a Service (SaaS) by hosting applications or other machine-readable instructions; Infrastructure as a Service (IaaS) by hosting equipment (servers, storage components, network components, etc.); or a Platform as a Service (PaaS) by hosting a computing platform (operating system, hardware, storage, and so forth). 
     A hybrid cloud is a public and/or private cloud environment at which IaaS or PaaS is offered by a cloud service provider. The services of the public cloud may be used to deploy applications. In other examples, a hybrid cloud may also offer SaaS, such as in examples where the public cloud offers the SaaS as a utility (e.g. according to a subscription or pay as you go model). Hybrid clouds implement virtualization technology to deploy a virtual infrastructure based on native hardware. Virtualization technology has typically been employed via virtual machine (VMs), with each application VM having a separate set of operating system, networking and storage. However, containers are increasingly becoming a preferred choice for deployment of application workloads. 
    
    
     
       BRIEF DESCRIPTION OF THE DRAWINGS 
       In the following drawings like reference numbers are used to refer to like elements. Although the following figures depict various examples, one or more implementations are not limited to the examples depicted in the figures. 
         FIG. 1  illustrates one embodiment of an infrastructure management system. 
         FIG. 2  is a block diagram illustrating another embodiment of an infrastructure management system. 
         FIG. 3  illustrates yet another embodiment of an infrastructure management system. 
         FIG. 4A  and  FIG. 4B  illustrate embodiments of deployed infrastructure using Blueprints. 
         FIG. 5  illustrates one embodiment of a sequence diagram for operation of a management controller. 
         FIG. 6  is a block diagram illustrating one embodiment of a solver engine. 
         FIG. 7  illustrates one embodiment of a Recipe. 
         FIG. 8  is a flow diagram illustrating one embodiment of an instance mapping process. 
     
    
    
     DETAILED DESCRIPTION 
     In embodiments, an infrastructure management platform is provided to facilitate infrastructure management services between a client organization and one or more infrastructure resource provider organizations. In such embodiments, a management controller microservice manages physical infrastructure resources provided by a plurality of infrastructure services organizations based on a declarative description that specifies the resources requested by the client. 
     In the following description, for the purposes of explanation, numerous specific details are set forth in order to provide a thorough understanding of the present disclosure. It will be apparent, however, to one skilled in the art that the present disclosure may be practiced without some of these specific details. In other instances, well-known structures and devices are shown in block diagram form to avoid obscuring the underlying principles of the present disclosure. 
     Reference in the specification to “one embodiment” or “an embodiment” means that a particular feature, structure, or characteristic described in connection with the embodiment is included in at least one embodiment of the disclosure. The appearances of the phrase “in one embodiment” in various places in the specification are not necessarily all referring to the same embodiment. 
     Throughout this document, terms like “logic”, “component”, “module”, “engine”, “model”, and the like, may be referenced interchangeably and include, by way of example, software, hardware, and/or any combination of software and hardware, such as firmware. Further, any use of a particular brand, word, term, phrase, name, and/or acronym, should not be read to limit embodiments to software or devices that carry that label in products or in literature external to this document. 
     It is contemplated that any number and type of components may be added to and/or removed to facilitate various embodiments including adding, removing, and/or enhancing certain features. For brevity, clarity, and ease of understanding, many of the standard and/or known components, such as those of a computing device, are not shown or discussed here. It is contemplated that embodiments, as described herein, are not limited to any particular technology, topology, system, architecture, and/or standard and are dynamic enough to adopt and adapt to any future changes. 
       FIG. 1  illustrates one embodiment of an infrastructure management system  100  having a computing device  120  employing a management controller  110 . In one embodiment, management controller  110  is a microservice that facilitates management of physical infrastructure resources provided by a plurality of infrastructure services organizations. In a further embodiment, management controller  110  enables the management of those resources on behalf of a plurality of client (or customer) organizations via a declarative description (or Blueprint) that specifies resources requested by the client. In such an embodiment, a Blueprint provides an abstract description of compute, storage, networking and OS image resources that can be allocated and configured together to operate a virtual machine (VM) cluster or software application. Accordingly, Blueprints serve as a high level description used to request an execution venue (or venue) for deployment of application workloads via management controller  110 . In one embodiment, a venue may be defined as an environment at which client workloads may be executed. 
     As shown in  FIG. 1 , computing device  120  includes a host server computer serving as a host machine for employing management controller  110 , which provides a platform to facilitate management of infrastructure resources on behalf of customer organizations (or clients)  115  via a PaaS or IaaS. Computing device  120  may include (without limitation) server computers (e.g., cloud server computers, etc.), desktop computers, cluster-based computers, set-top boxes (e.g., Internet-based cable television set-top boxes, etc.), etc. Computing device  120  includes an operating system (“OS”)  106  serving as an interface between one or more hardware/physical resources of computing device  120  and one or more client devices  117 , etc. Computing device  120  further includes processor(s)  102 , memory  104 , input/output (“I/O”) sources  108 , such as touchscreens, touch panels, touch pads, virtual or regular keyboards, virtual or regular mice, etc. In one embodiment, management controller  110  may be executed by a separate processor application specific integrated circuit (ASIC) than processor  102 . In a further embodiment, management controller  110  may act out of band, and may be on a separate power rail, from processor  102 . Thus, management controller  110  may operate on occasions in which processor  102  is powered down. 
     In one embodiment, host organization  101  may further employ a production environment that is communicably interfaced with client devices  117  at customer organizations  115  through host organization  101 . Client devices  117  may include (without limitation) customer organization-based server computers, desktop computers, laptop computers, mobile computing devices, such as smartphones, tablet computers, personal digital assistants, e-readers, media Internet devices, smart televisions, television platforms, wearable devices (e.g., glasses, watches, bracelets, smartcards, jewelry, clothing items, etc.), media players, global positioning system -based navigation systems, cable setup boxes, etc. 
     In one embodiment, the illustrated database(s)  140  store (without limitation) information and underlying database records having customer and user data therein on to process data on behalf of customer organizations  115 . In some embodiments, host organization  101  receives input and other requests from a plurality of customer organizations  115  over one or more networks  135 ; for example, incoming data, or other inputs may be received from customer organizations  115  to be processed using database system  140 . 
     In one embodiment, each customer organization  115  is an entity selected from a group consisting of a separate and distinct remote organization, an organizational group within host organization  101 , a business partner of host organization  101 , a customer organization  115  that subscribes to cloud computing services provided by host organization  101 , etc. 
     In one embodiment, requests are received at, or submitted to, a web server within host organization  101 . Host organization  101  may receive a variety of requests for processing by host organization  101 . For example, incoming requests received at the web server may specify services from host organization  101  are to be provided. Further, host organization  101  may implement a request interface via the web server or as a stand-alone interface to receive requests packets or other requests from the client devices  117 . The request interface may further support the return of response packets or other replies and responses in an outgoing direction from host organization  101  to one or more client devices  117 . 
     In one embodiment, computing device  120  may include a server computer that may be further in communication with one or more databases or storage repositories, such as database(s)  140 , which may be located locally or remotely over one or more networks, such as network(s)  135  (e.g., cloud network, Internet, proximity network, intranet, Internet of Things (“IoT”), Cloud of Things (“CoT”), etc.). Computing device  120  is further shown to be in communication with any number and type of other computing devices, such as client computing devices  117 , over one or more networks, such as network(s)  135 . 
     In one embodiment, computing device  120  may serve as a service provider core for hosting and management controller  110  as a SaaS or IaaS, and be in communication with one or more client computers  117 , over one or more network(s)  135 , and any number and type of dedicated nodes. In such an embodiment, host organization  101  provides infrastructure management to resources provided by resource providers  121 A- 121 N. Resource providers  121 A- 121 N represent separate infrastructure resource providers that offer services to provide hardware resources (e.g., compute, storage, network elements, etc.) or software resources. In a further embodiment, one or more of providers  121 A- 121 N may provide a virtualization of its resources as a virtualization infrastructure for virtualization of its resources. In this embodiment, computing device  120  resources and/or one or more of the physical infrastructure resources provided by providers  121 A- 121 N may be configured as one or more Point of Developments (PODs) (or instance machines), where an instance machine (or instance) comprises a cluster of infrastructure (e.g., compute, storage, software, networking equipment, etc.) that operate collectively. 
     According to one embodiment, each of the providers  121 A- 121 N implement an on-premise infrastructure controller  130  to control its respective resources. In this embodiment, each infrastructure controller  130  represents an on-premise infrastructure system (e.g., data center) that provides one or more infrastructure elements (e.g., an instance of managed infrastructure) of its respective resources. In one embodiment, each infrastructure controller  130  may comprises one or more software-defined networking (SDN) controllers that provide on-premises infrastructure management of physical infrastructure resources, such as a OneView® Infrastructure Management System. However other embodiments may implement different infrastructure management systems. 
       FIG. 2  is a block diagram illustrating another embodiment of an infrastructure management system  100 . As shown in  FIG. 2 , infrastructure management system  100  may include the management of resources within data centers or edge devices. For example, infrastructure management system  100  includes a data center  250 A having resources  251 - 253 , data center  250 A having resources  254  and  255 , and an edge device  260  having resources  262  (e.g., routers, routing switches, integrated access devices (IADs), multiplexers, etc.). Additionally, data center  250 A includes infrastructure controllers  221 A and  221 B. In one embodiment, infrastructure controller  221 A manages one or more resources within each of resources  251  and  252 , while infrastructure controller  221 B manages one or more resources within each of resources  251  and  252 . Similarly, infrastructure controller  221 C manages resources within each of resources  254  and  255  within data center  250 B, as well as resources  262  within edge device  260 . 
     According to one embodiment, management controllers  210  are coupled to the infrastructure controller  221 . For example, management controller  210 A is a cloud controller (e.g., as discussed in  FIG. 1 ) that manages all of the resources via infrastructure controllers  221 A- 221 C. However in other embodiments, a management controller  210  may be implemented outside of the cloud. For example, management controller  210 B may be physically located in data center  250 A to manage all of the resources via infrastructure controllers  221 A- 221 C. During an initial registration of an infrastructure controller  221 , a controller  221  transmits to controller  210  a full list of resources that it controls. For example, infrastructure controller  221 C may inform each management controller  210  that it controls resources  254 ,  255  and  262 . 
       FIG. 3  illustrates yet another embodiment of an infrastructure management system  100 , including a management controller  210  and infrastructure controllers  221 A- 221 N that directly control managed resources  280 . According to one embodiment, management controller  210  includes an application programming interface (API)  301  to receive Blueprints from clients (e.g., client device  117  in  FIG. 1 ). As discussed above, a Blueprint is an abstract description of compute, storage, networking and OS image resources to be allocated to a client as a unit of compute/venue for workload deployment. For example, a Blueprint may specify that “I want a DL server on Network A”, or “I want a pair of DL servers on Network A, with a private network between them and shared storage.” 
     Management engine  310  receives a Blueprint via API  301  and tracks all transaction via a database  340 . In one embodiment, a solver engine  320  receives the Blueprint from management engine  310  and translates the Blueprint into a set of high level steps (or Recipe) needed to instantiate the requested resources.  FIG. 4A  and  FIG. 4B  illustrate embodiments of deployed infrastructure  400  using Blueprints. As shown in  FIG. 4A  and  FIG. 4B , the above exemplary Blueprint statements are converted to inputs and outputs, as well as an output on creation. In other embodiments, a Blueprint may include a statement to discontinue or remediate existing allocated resources. 
     Once the Blueprint conversion is performed, solver engine  320  creates a blueprint instance associated of the Blueprint and forwards a resource request to broker  330 , which broadcasts the request to the infrastructure controllers  221 . According to one embodiment, broker  330  broadcasts requests to infrastructure controllers  221  via adapters  360 . In such an embodiment, each adapter  360  operates as a bridge to an infrastructure manager  221 . Thus, adapters  360 A- 360 N are implemented to interface with  221 A- 221 N. In a further embodiment each adapter  360  is communicatively coupled to an agent  321  within an infrastructure controller  221 . In this embodiment, an agent  321  operates as an on-premise component that performs functions on an infrastructure controller  221  instance on behalf of an associated adapter  360 . Such functions may include actuating the infrastructure controller  221  instance to create, destroy and remediate blueprint instances. 
     Agents  321  may also transmit state change notifications to an adapter  360  for infrastructure elements and heartbeat. In one embodiment, received state changes are maintained at database  350 . Database  350  maintains an inventory of resources provided by each infrastructure controller  221  registered with management controller  210 . In a further embodiment, database  350  maintains a cache of a state function of each resource associated with an infrastructure controller  221 . Thus, any change in state of resource associated with the infrastructure controller  221  is forwarded to management controller  210 , where it is stored in database  350 . 
     Sometime after broadcasting the request, broker  330  receives proposals from one or more infrastructure controllers  221 . In one embodiment, a proposal indicates a request by an infrastructure manager  221  to provide all or some of the requested resources that were broadcasted. For example, upon receiving a broadcast requesting  60  server resources, infrastructure controller  221 A may propose providing  30  server resources, while infrastructure controller  221 B may propose providing all 60 server resources. In one embodiment, solver engine  320  receives the proposals and determines which proposal and performs a mapping that best matches the Blueprint request. Subsequently, solver engine transmits a notification to client  117  from which the Blueprint was received via a notification engine  302 . In a further embodiment, solver may select two or more proposals that match the request and forward for selection by a user at client  117 . 
     Upon acceptance of a proposal, one or more adapters  360  facilitate instantiation of a resource instance with one or more infrastructure controllers  221  that will be providing the resources. Subsequently, the infrastructure controllers  221  assign the resources internally. For example, an accepted proposal may specify that  30  server resources are to be provided by infrastructure controller  221 A and another  30  server resources are to be provided by infrastructure controller  221 B. Thus, adapters  360  for infrastructure controller  221 A and infrastructure controller  221 B assign the required resources and forwards the resource assignments back to management controller  210 , where the resource assignments are stored a database  340  by management engine  310  along with the associated Blueprint and blueprint instance. 
       FIG. 5  illustrates one embodiment of a sequence diagram for operation of management controller  210 . At stage  1 , a Blueprint is created at API  301  (e.g., via a client). At stages  2 A and  2 B, the Blueprint is saved and applied at management engine  310 , respectively. At stages  3 A and  3 B, the Blueprint and an associated Blueprint instance is saved to storage (e.g., database  350 ). At stages  4 A and  4 B, Blueprint creation is published and an instance of the request in the Blueprint is created, respectively. At this stage the Blueprint creation process has completed. 
     At stage  5 , solver engine  320  transmits a resources request to broker  330 , which subsequently broadcasts the request to infrastructure controllers  221  via adapters  360 . At stage  6 , proposals are received at broker  330  from the infrastructure controllers  221 . At stage  7 , the proposals are published via one or more notifications at notification engine  302 . At stage  8 , a notification indicating acceptance of the proposal is received at solver engine  320  via API  301  and forwarded to one or more infrastructure controllers  221  via adapters  360 . As a result, the resources are allocated at the infrastructure controllers  221 . At stage  9  a notification is received from the one or more infrastructure controllers  221  and published via notification engine  302  indicating to the client that the resources have been allocated. 
     As discussed above, solver engine  320  performs a mapping of management controller  210  instances and infrastructure controller  221  instances. As used herein, a management controller instance includes one or more instances implemented to provision and manage resources to create and manage venues of workload deployments. As used herein, an infrastructure controller instance includes one or more instances that manages on-premise physical infrastructure. In one embodiment, the instance mapping performed by solver engine  320  provides a matching (or pairing) of instances created based on user preferences received from a client  217  to resource instances managed by an infrastructure controllers  221  via adapters  360 . In this embodiment, the user preferences comprise one or more configuration parameters included in a Blueprint.  FIG. 6  is a block diagram illustrating one embodiment of a solver engine  320 . 
     As shown in  FIG. 6 , solver engine  320  includes a registry engine  602 . In one embodiment, each infrastructure controller  221  registers with solver engine  320  via during a discovery process performed by registry engine  602  in which an infrastructure controller  221  registers. During the discovery process, an infrastructure controller  221  provides a resource capabilities listing (e.g., software and/or hardware resources managed by the infrastructure controller  221 ), which registry engine  602  stores in database  350 . In a further embodiment, registration information may include costs (or prices charged) to use resources managed by the infrastructure controller  221 . 
     Solver engine  320  also includes a translator  605  to translate the Blueprint configuration parameters into a Recipe comprising a set of steps having resource attributes corresponding to the configuration parameters. In one embodiment, solver engine  320  includes a compiler to translate the Blueprint into the Recipe steps. In such an embodiment, solver  320  transforms a recipe into a Blueprint using a deductive algorithm and/or extensible predefined catalogs. For example, Blueprint to Recipe translation steps can be obtained from scripts developed in advance, an extensible Blueprint catalog, or via locally computed or web delivered insights or deductions  FIG. 7  illustrates one embodiment of a Recipe  700  including various configuration parameters comprised within high level steps. 
     Solver engine  320  further includes a mapper  610  to perform the mapping (or pairing) of management controller  210  instances (or management instances) and infrastructure controller  221  instances (or resource instances). In one embodiment, mapper  610  performs the mapping based on the Recipe resource attributes translated from the Blueprint configuration parameters. In such an embodiment, mapper  610  matches resource capabilities provided by one or more infrastructure controllers  221  during registration with the resource attributes included in the Recipe. 
     In a further embodiment, management instances and resource instances are mapped using an m:n cardinality construct. In such an embodiment, mapper  610  maintains a set of data structures within database  340  to track management controller  210  resources (e.g., management tables) and another set of data structures to track resources associated with each infrastructure controller  221  (e.g., infrastructure tables). Accordingly, the m:n mapping provides that each row in the management tables may reference many rows in the infrastructure tables, and each row in the infrastructure tables may reference many rows in the management tables. 
     As discussed above, the mapping may be performed based on user configuration parameters (or criteria). In one embodiment, Blueprint configuration parameters may define one or more latency constraints. For example, the configuration parameters may indicate user preferences to ensure that latency between management controller  210  and infrastructure controllers  221  does not exceed a defined threshold value, or ensure that providers of infrastructure controllers  221  are restricted to defined geographical locations due to bandwidth considerations. 
     In another embodiment, Blueprint configuration parameters may define infrastructure and data locality. For instance, the configuration parameters may provide for geographical (or other locational affinity) constraints due to data locality, compliance and regulatory constraints, which is typically a consideration for security/audit administration clients. In yet another embodiment, Blueprint configuration parameters may define disaster recovery considerations (e.g., availability zones). In still another embodiment, Blueprint configuration parameters may define power (or other types of infrastructure costs) as driving factors in the matching management controller  210  and infrastructure controllers  221  instances. 
     Based on all of the defined Blueprint configuration parameters, mapper  610  maps available management instances to one or more infrastructure controllers  221  that satisfy the configuration parameter constraints. Thus, management controller  210  performs a search of database  350  to find the infrastructure controllers  221  having resources that satisfies the criteria, and assigns those resources to a management controller  210  instance. Subsequently, mapper  610  updates the mapping in database  340  (e.g., instance and resources used), as well of the status of the resource inventory in database  350  (e.g., resource status changed from unused to used). 
     According to one embodiment, solver engine  320  also implements a learning model  615  to assist in the resource mapping performed by mapper  610 . In such an embodiment, learning model  615  performs a machine learning algorithm to learn customer preferences based on how clients have previously performed a manual deployment (and/or adjustment) of management controller  210  and infrastructure controller  221  instances and how they move them around afterwards. Thus, learning model  615  captures client pairing data (e.g., how often resource instances are used, modified and/or deleted) to establish suitable mappings. As a result, learning model  615  may capture anonymous data for all clients to review trends over time that can then drive individual recommendations for specific clients based on previous configurations. 
     In a further embodiment, solver engine  320  includes a monitor  620  to monitor resource service conditions and automatically modify (or adjust) mappings based on those conditions. In such an embodiment, monitor  620  may receive, a state change notification from an infrastructure controllers  221  (e.g., via an associated agent  321  and adapter  360 ) indicating that access to the resources has been interrupted. For example, a change notification may be received in response to a surge in infrastructure demand due to promotional offerings, or upon a regulatory occurrence (e.g., Brexit) that may change the cost dynamics of infrastructure (e.g., due to tariffs, taxes. etc.). 
     In response to receiving a state change notification mapper  610  may dynamically remap management instances to other resource instances. For example, a management instance mapped to resource instances within infrastructure controller  221 A may be remapped to resource instances within infrastructure controller  221 B upon monitor  620  detecting that access to the infrastructure controller  221 A resources has been interrupted. 
       FIG. 8  is a flow diagram illustrating one embodiment of an instance mapping process performed at management controller  210 . At processing block  810 , a Blueprint including one or more configuration parameters is received. At processing block  820 , the Blueprint is translated into a Recipe including a steps of resource attributes corresponding to the configuration parameters. Subsequently, a request for resources is broadcast to registered infrastructure controllers  221 . At processing block  830 , various proposals are received from the infrastructure controllers  221 . Once a proposal is accepted by a user, management instances are mapped to resource instances based on the resource attributes indicated in the accepted proposal, processing block  840 . At processing block  850 , resource service conditions are monitored. At processing block  860 , a determination is made as to whether a state change notification is received indicating that access to the resources has been interrupted. If so, control is returned to processing block  840 , where the management instances are mapped to new resource instances that satisfy the configuration parameters. Otherwise, control is returned to processing block  850 , where the resource service conditions continue to be monitored. 
     Embodiments may be implemented as any or a combination of: one or more microchips or integrated circuits interconnected using a parent board, hardwired logic, software stored by a memory device and executed by a microprocessor, firmware, an application specific integrated circuit (ASIC), and/or a field programmable gate array (FPGA). The term “logic” may include, by way of example, software or hardware and/or combinations of software and hardware. 
     Embodiments may be provided, for example, as a computer program product which may include one or more machine-readable media having stored thereon machine-executable instructions that, when executed by one or more machines such as a computer, network of computers, or other electronic devices, may result in the one or more machines carrying out operations in accordance with embodiments described herein. A machine-readable medium may include, but is not limited to, floppy diskettes, optical disks, CD-ROMs (Compact Disc-Read Only Memories), and magneto-optical disks, ROMs, RAMs, EPROMs (Erasable Programmable Read Only Memories), EEPROMs (Electrically Erasable Programmable Read Only Memories), magnetic or optical cards, flash memory, or other type of media/machine-readable medium suitable for storing machine-executable instructions. 
     Moreover, embodiments may be downloaded as a computer program product, wherein the program may be transferred from a remote computer (e.g., a server) to a requesting computer (e.g., a client) by way of one or more data signals embodied in and/or modulated by a carrier wave or other propagation medium via a communication link (e.g., a modem and/or network connection). 
     The drawings and the forgoing description give examples of embodiments. Those skilled in the art will appreciate that one or more of the described elements may well be combined into a single functional element. Alternatively, certain elements may be split into multiple functional elements. Elements from one embodiment may be added to another embodiment. For example, orders of processes described herein may be changed and are not limited to the manner described herein. Moreover, the actions in any flow diagram need not be implemented in the order shown; nor do all of the acts necessarily need to be performed. Also, those acts that are not dependent on other acts may be performed in parallel with the other acts. The scope of embodiments is by no means limited by these specific examples. Numerous variations, whether explicitly given in the specification or not, such as differences in structure, dimension, and use of material, are possible. The scope of embodiments is at least as broad as given by the following claims.