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 an 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).
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.
As discussed above, resources may be implemented to provide a cloud service. However, cloud services are increasingly incorporating edge nodes including edge devices (e.g., servers and storage) into cloud platforms to provide compute and storage capabilities in close proximity to a location that needs those resources (e.g., a location of end users). Edge servers often incorporate baseboard management controllers (BMCs) to facilitate out-of-band management of the servers (e.g., use of management interfaces for managing and networking equipment). However, cloud management services and edge servers may not support the same communication protocols. Thus, out-of-band management of the servers by a cloud management service requires a separate controller physically coupled to each edge server to enable communication between a cloud management service and edge servers to perform out-of-band management.
In embodiments, a translation service is provided as a SaaS or PaaS to facilitate cloud management of edge server communication. In such embodiments, the translation service receives an operation request (or request operation or request) from a cloud service (or source) in a communication protocol supported by the cloud service and translates the request to a communication protocol supported by the edge server before transmitting the translated request to the edge server (or destination). In further embodiments, the translation service receives an operation response (or response) to the request from the edge server in the communication protocol supported by the edge server and translates the response to the communication protocol supported by the cloud service for transmission to the source. In yet further embodiments, the translation service supports a plurality of communication protocols (e.g., Hypertext Transfer Protocol Secure (HTTPS), Representational state transfer (REST), gRPC Remote Procedure Calls (gRPC), etc.). Thus, the translation service enables a cloud service to simultaneously communicate with two or more edge servers that support different communication protocols.
As used herein, a “Baseboard Management Controller” or “BMC” is a specialized service processor that monitors the physical state of a server or other hardware using sensors and communicates with a management system through an independent “out-of-band” connection. The BMC may also communicate with applications executing at the OS level through an input/output controller (IOCTL) interface driver, a REST application program interface (API), or some other system software proxy that facilitates communication between the BMC and applications. The BMC may have hardware level access to hardware devices located in a server chassis including system memory. The BMC may be able to directly modify the hardware devices. The BMC may operate independently of the OS of the system that the BMC is located in. The BMC may be located on the motherboard or main circuit board of the server or other device to be monitored. The fact that a BMC is mounted on a motherboard of the managed server or otherwise connected or attached to the managed server does not prevent the BMC from being considered “separate”. As used herein, a BMC has management capabilities for sub-systems of a computing device, and is separate from a processing resource that executes an OS of a computing device. The BMC is separate from a processor, such as a central processing unit, executing a high level OS or hypervisor on a system.
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, host organization 101 provides services to configure resources within data centers 121A-121N. Data centers 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 data centers 121A-121N implement one or more on-premise infrastructure controller 130 to control its respective resources. In this embodiment, each infrastructure controller 130 controls an on-premise infrastructure appliance, which provides access to infrastructure devices within the appliance, or to one or more infrastructure elements (e.g., an instance of managed infrastructure) of its respective infrastructure resources. In one embodiment, each infrastructure controller 130 comprises a software-defined networking (SDN) controller that provide on-premises infrastructure management of physical infrastructure resources, such as an Infrastructure Management System. However other embodiments may implement different infrastructure management systems.
BMC API 318 is implemented to communicate with BMC 378 at edge server 370 to perform management and provisioning services. BMC API 318 communicates with BMC 378 to perform server 370 management operations (e.g., power-up, reset, update firmware, set BIOS, set Boot disk, get serial number, etc.). Similar to API 314, BMC API 318 may also comprise a gRPC interface to facilitate communication with BMC 378. However in many instances, BMC 378 may implement a different type of interface. For example, BMC 378 may operate according to a Representational state transfer (REST) protocol interface.
According to one embodiment, cloud manager 210 includes a bridge controller 350 that implements a translation service 355 to translate between a communication protocol supported by BMC API 318 (or protocol 1 (e.g., gRPC)) and a communication protocol supported by BMC 378 (or protocol 2 (e.g., REST)). Thus, translation service 355 operates as a communication bridge in instances in which cloud services 310 and BMC 378 do not support the same communication protocol. In further embodiments, translation service 355 supports other communication protocols (e.g., Hypertext Transfer Protocol Secure (HTTPS), WebSocket (WS), WebSocket Secure (WSS), etc.) in addition to gRPC and REST.
In one embodiment, translation service 355 includes a translation table 357 that is implemented to perform the translation between protocol 1 operations and protocol 2 operations. In this embodiment, translation table 357 comprises a database including a plurality of request and response operations supported by each communication protocol. Additionally, the translation table 357 database maintains an index of related operations between a communication protocol that is supported by BMC API 318 and communication protocols supported by each of a plurality of BMCs 378.
For example, a protocol 1 (e.g., gRPC) power on API request may be indexed to a protocol 2 (e.g., REST) power on API request supported at a first BMC 378, and indexed to a protocol 3 (e.g., HTTP) power on API request supported at a second BMC 378. Thus, translation is performed by replacing the protocol 1 request format with the protocol 2 request format (or the protocol 3 format). A similar translation process is performed from protocol 2 (or protocol 3) to protocol 1 for responses received at translation service 355 from a BMC 378. In other embodiments, translation service 355 may implement different types of translation mechanisms. For example, translation service 355 may employ a trained machine learning algorithm to facilitate the translations.
In one embodiment, translation service 355 may simultaneously perform translations between BMC API 318 and a BMC 378 at multiple edge servers 370. In such an embodiment, each communication channel between translation service 355 and a BMC 378 comprises a secure channel (e.g., a Transport Layer Security (TLS) protocol tunnel) to transmit requests and responses. As a result, different cloud service sources may use translation service 355 simultaneously to provision a plurality of edge servers 370 supporting various communication protocols.
According to one embodiment, translation service 355 provides a fallback process to support edge servers 370 that do not have a persistent and reliable network connectivity to cloud manager 210. In such an embodiment, translation service 355 immediately translates requests received from the source to the supported protocol and transmits the requests to the destination edge server 370. In instances in which the connection between translation service 355 and the BMC 378 has been interrupted (e.g., BMC 378 does not receive a request due to a network disconnect or timeout), translation service 355 waits to be contacted by BMC 378 once the connection has been re-established.
In this embodiment, translation service 355 receives an update message from BMC 378 requesting an operation that is to be performed. In response, translation service 355 transmits a status update message to BMC API 318 requesting a most recent operation requested to be performed on the BMC 378. Subsequently, BMC API 318 repeats the transmission of the original request to translation service 355 for translation and transmission to BMC 378. Thus, there is no need for translation service 355 to cache server states, operations to perform, or any other data that by required by edge server 370 or BMC API 318.
In one embodiment, the processing comprises forwarding the request to a destination process managed by BMC 378. The destination process performs one or more of the BMC operations discussed above and generates a response. Once processing has been completed the generated response is transmitted from edge server 370 and received at translation service 355, processing block 440. At processing block 450, translation service 355 translates the response (e.g., from protocol 2 to protocol 1). At processing block 460, the translated response is transmitted to the originating source.
As mentioned above, a fallback process is performed by translation service 355 for instances in which the connection with BMC 378 has been interrupted.
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.
Number | Name | Date | Kind |
---|---|---|---|
10528551 | Li et al. | Jan 2020 | B2 |
10699668 | Gupta | Jun 2020 | B1 |
20050257258 | Kinoshita | Nov 2005 | A1 |
20140281708 | Adam | Sep 2014 | A1 |
20160191461 | Wang | Jun 2016 | A1 |
20190005576 | Mick et al. | Jan 2019 | A1 |
20190141119 | Bernat | May 2019 | A1 |
20190227949 | Bernat | Jul 2019 | A1 |
20190349426 | Smith | Nov 2019 | A1 |
20200328948 | Nayyar | Oct 2020 | A1 |
20210203617 | Johansson | Jul 2021 | A1 |
20210211509 | Ly | Jul 2021 | A1 |
Number | Date | Country |
---|---|---|
108769250 | Nov 2018 | CN |
Entry |
---|
Chinthaka Deshapriya, “OpenStack Metal-as-a-Service,” May 19, 2017, pp. 1-18, Retrieved from the Internet on Jun. 8, 2020 at URL: <slideshre.net/openedasia/openstack-metaservice>. |
Hewlett Packard Enterprise Development LP, “Redfish API implementation on HPE servers with iLO RESTful API,” Technical White Paper, Dec. 2017, pp. 1-9. |
Matti Dahlbom, “Cloud Conversion, Part 1: Cloud Endpoints API,” May 8, 2017, pp. 1-6, Retrieved from the Internet on Jun. 9, 2020 at URL: <ovik.com/news/cloud-conversion-1/>. |
Shweta Gupta, “Configuring Hyperledger Fabric consodium with Gracie Blockchain Cloud Service (OBCS),” May 12, 2019, p. 1-11, Retrieved from the Internet on Aug. 9, 2020 at URL:<medium.com@shwartagupta9/configuring-hyperledger-fabric-consortium-with-oracle-blockchain-cloud-service-obcs-516271s104d>. |
Tinkerbell, “Provision and Manage Bare Metal, Anywhere,” 2020, pp. 1-2. |
Number | Date | Country | |
---|---|---|---|
20210399994 A1 | Dec 2021 | US |