Patent Application
20210240626
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.
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.
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 automatically balances utilization of infrastructure resources between a plurality of on-premise infrastructure controllers. In a further embodiment, the management controller microservice includes a cache update prediction mechanism that monitors the frequency of cache updates in order to generate predicted times of arrival for data updates from a plurality of data sources to the cache.
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.
As shown in
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 121A-121N. Resource providers 121A-121N 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 121A-121N 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 121A-121N 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 121A-121N 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.
Additionally, data center 250A includes infrastructure controllers 221A and 221B. In one embodiment, infrastructure controller 221A manages one or more resources within each of resources 251 and 252, while infrastructure controller 221B manages one or more resources within each of resources 251 and 252. Similarly, infrastructure controller 221C manages resources within each of resources 254 and 255 within data center 250B, 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 210A is a cloud controller (e.g., as discussed in
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.
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 controller 221. Thus, adapters 360A-360N are implemented to interface with 221A-221N. 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 controller 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 221A may propose providing 30 server resources, while infrastructure controller 221B 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 221A and another 30 server resources are to be provided by infrastructure controller 221B. Thus, adapters 360 for infrastructure controller 221A and infrastructure controller 221B 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.
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.
As shown in
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.
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 one embodiment, resource instances may be configured according to default configuration parameters prior to mapping to a Blueprint (e.g., pre-Blueprint configurations).
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 resource manager 620 including a monitor 625 to monitor resource service conditions and automatically modify (or adjust) mappings based on those conditions. In such an embodiment, monitor 625 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 221A may be remapped to resource instances within infrastructure controller 221B upon monitor 625 detecting that access to the infrastructure controller 221A resources has been interrupted.
Resource manager 620 also includes a cache update prediction (or prediction) engine 627 that is implemented to monitor the frequency of updates to a cache 629 and predict a rate of update of data stored for each of a plurality of data sources. Based on the rate of update prediction engine 627 may predict an arrival time of a subsequent update to the data cache for each data source. According to one embodiment, cache 629 stores infrastructure resource data for each of a plurality of data sources. In such an embodiment, a data source may comprise an IC 221 that controls a plurality of infrastructure devices, an individual resource device (e.g., server, storage, etc.), software application, etc.
In a further embodiment, each data source periodically updates cache 629 by transmitting data (e.g., a data stream) including current resource status information regarding the particular data source. In this embodiment, each data stream includes a unique identifier (or ID) associated with a data source to identify the data source from which a data stream has been received. Prediction engine 627 observes the frequency of updates for each data source and uses the learned information to predict a time of arrival for subsequent cache updates from the respective data sources.
According to one embodiment, prediction engine 627 includes gradient descent logic 628 to monitor the data source updates. In such an embodiment, gradient descent logic 628 implements a gradient-descent machine learning algorithm to learn the frequency of updates and predict future update arrival times. Gradient descent is an optimization algorithm used to minimize a function by iteratively moving in a direction of a steepest descent as defined by a negative of a gradient (e.g., a direction and rate of fastest increase). Thus, gradient descent logic 628 is used to update various model parameters. In one embodiment, gradient descent logic 628 implements observation parameters and adjustment for each data source. The observation parameters comprise running mean and running standard deviation parameters, while the adjustment parameters comprise observed mean and observed variance parameters that are used as linear regression multipliers. Accordingly, gradient descent logic 628 predicts an arrival time of a next update using a linear expression including the observed mean and observed variance multiplier values.
In one embodiment, the observed mean and observed variance multipliers for each data source are initialized with the values 1 and 0.3, respectively, prior to receiving cache updates. However other embodiments may feature different initialization values. As updates are received for a data source, gradient descent logic 628 continually adjusts the observed mean and observed variance values to minimize a root-mean-square error between predicted time of arrival values and actual (or observed) time of arrival values. Thus, the root-mean-square error minimization results in a generated predicted arrival time of a subsequent update.
In one embodiment, gradient descent logic 628 generates a time of arrival value associated with a time at which a data stream comprising a most recent update has been received at cache 629 from a data source. Subsequently, the observed mean and observed variance values are adjusted, and a predicted time of arrival value is generated based on the adjusted values.
Accordingly, gradient descent logic 628 implements an iterative process to learn the frequency of cache updates for a data source in order to generate a predicted time of arrival for a next update. Further, only the observed mean and observed variance values are required to be stored for prediction engine 627 to predict arrival times only by adjusting. As a result, it is not necessary to store past update time of arrival values.
In a further embodiment, prediction engine 627 may generate a rate of update (or staleness) value for each data source. In such an embodiment, the staleness value comprises a percentage represented as an elapsed time since a most recently received data update (e.g., time of arrival value) divided by a delay time until the predicted arrival time value of a subsequent data update. Thus, the staleness value is zero immediately after arrival of an update and it increases linearly until the next update arrives. As an example, a staleness value is represented as 10% in a scenario in which one hour has elapsed since a most recently received data update for a data source has been received and the predicted time of arrival is 10 hours.
In one embodiment, the staleness value may exceed 100% in instances in which a data update has not been received by the predicted time of arrival. For example, the staleness value may be calculated at 120% upon a determination that 12 hours have elapsed since a most recently received data update for a data source has been received and the predicted time of arrival is 10 hours. This may indicate that there a problem is occurring at, or communication with, the data source. As a result, an alert may be generated indicating that the currently cached data for the data stream has exceed an expiration time, and is unreliable.
At processing block 730, the observed mean and observed variance values are adjusted. Based on the adjustment, a predicted time of arrival value is generated, at processing block 740. As discussed above, the predicted time of arrival value is generated by minimizing a root-mean-square error between predicted time of arrival values and actual (or observed) time of arrival values. At processing block 750, the predicted time of arrival value is reported. As mentioned above, the predicted time of arrival value may be reported as a staleness value that represents a percentage indicating an elapsed time since a most recently received data update. A staleness percentage of 100% or greater indicates that the currently cached data is stale, and thus unreliable.
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.
